Scope OF System practice questions

The end-user's local home router configuration.

Why it fails: End-user equipment is typically outside the system boundary.

The public internet backbone routing protocols.

Why it fails: The public internet is outside the control of the information system owner.

The organization's global human resources policy.

Why it fails: HR policy is an organizational common control, not a system-specific component.

The high water mark only applies to federal systems with 'High' impact data.

Why it fails: It applies to all federal systems, regardless of the final rating.

Categorization must be performed by averaging the impact scores.

Why it fails: Averaging is not permitted under NIST guidance.

The high water mark is only determined by availability.

Why it fails: It is determined by the highest of all three objectives.

The local library book catalog.

Why it fails: This is not an information system resource managed by the agency under RMF.

The public social media feed of the organization.

Why it fails: Social media is an external platform, not a system component.

Define the boundary at the cloud provider's data center perimeter to ensure all hardware is covered.

Why it fails: Defining the boundary at the provider's data center perimeter would encompass infrastructure and personnel outside the organization's control, making the authorization package unmanageable. The boundary should reflect the system's logical and physical assets under the organization's direct authority, not the provider's facility perimeter.

Include the cloud infrastructure within the boundary because the system cannot function without it.

Why it fails: Including the cloud provider's infrastructure inside the boundary expands the scope to assets the organization does not own or control, which contradicts the RMF principle that the boundary should encompass assets under the organization's authority. The provider's infrastructure is typically covered by separate authorizations or FedRAMP packages, and pulling it into the boundary would create unrealistic assessment obligations.

Include only the virtual server and managed database, but exclude the physical cloud infrastructure.

Why it fails: Even the virtual server and managed database are provider-managed services; including them but excluding the underlying infrastructure creates an inconsistent boundary that still requires assessing controls the organization does not implement. The better approach is to treat the entire cloud service as external and inherit its controls, rather than arbitrarily splitting layers.

The shared database service that stores CUI on behalf of multiple systems.

Why it fails: A shared database service used by multiple systems is typically considered a common control or an external service, not part of a single system's authorization boundary. Its security is managed at an organizational level, and its inclusion would expand the boundary unnecessarily. The architect should instead rely on the shared service's own authorization or leverage its controls through inheritance.

The network switch that routes traffic between the system and the authentication server.

Why it fails: Network switches are generally part of the underlying infrastructure and are not included in a system's authorization boundary unless they are dedicated solely to that system. Shared network components are typically covered by the organization's infrastructure authorization. Including them would complicate the boundary and duplicate oversight, so they are not considered system components.

The cloud service provider's physical security guards who protect the data center.

Why it fails: Physical security guards are part of the cloud service provider's infrastructure and are typically covered under the provider's own authorization or as a common control. They are not unique to the system and do not process, store, or transmit the system's data. Therefore, they should not be included in the system boundary, but their controls can be inherited.

The backup server that stores CUI backups.

Why it fails: The backup server stores copies of CUI and is often considered part of the system boundary because it handles the same data. However, in many architectures, backup infrastructure is shared across multiple systems and may be authorized separately as a common control provider. The question asks for components typically included; while it could be included, the web front end and application server are more consistently core components.

The cloud provider's hypervisor that hosts the virtual machines.

Why it fails: The hypervisor is part of the cloud provider's infrastructure and is not under the organization's direct control. It is typically excluded from the boundary and addressed through inherited controls from the provider's authorization. Including it would require assessing the provider's internal operations, which is not feasible or necessary for the system's authorization.

The network switch that routes traffic between the web front end and the application server.

Why it fails: A network switch is typically part of the shared infrastructure that supports multiple systems. While it may carry CUI, it is often excluded from a single system's boundary and instead covered by a general support system or the organization's network authorization. Including every switch would make boundaries unmanageable and duplicate assessments across systems.

Include the entire database server in the boundary because the operating system is shared and cannot be logically separated.

Why it fails: Including the entire database server would bring the other department's database into the boundary, even though it is logically separated. While the operating system is shared, the other database may not be part of the system being authorized. The practitioner should assess whether the shared component introduces risk that requires inclusion or whether it can be treated as an external dependency.

Exclude the database server from the boundary because it is shared with another department and therefore cannot be authorized.

Why it fails: Excluding the database server entirely would leave a critical component of the system unassessed. The database server processes data for the system, so it cannot be simply excluded. The practitioner must determine how to handle the shared component, possibly by including the relevant logical instance and documenting the shared infrastructure.

Include only the database instance used by the system and exclude the operating system, because the operating system is a shared infrastructure component.

Why it fails: Excluding the operating system would ignore the foundational controls that protect the database instance. The operating system provides critical security functions such as authentication, access control, and patching. Even though it is shared, it is part of the environment that supports the system, so it must be included or its controls must be inherited and documented.

The network infrastructure that connects the dedicated server to the external identity management system.

Why it fails: The network infrastructure is typically considered part of the environment or a common control, not the system boundary itself. While it supports the system, it is often managed by a separate network team and authorized under a different boundary. Including it would complicate the authorization process and may duplicate efforts.

The external identity management system that provides authentication services.

Why it fails: The external identity management system is a separate system with its own authorization boundary. It may be leveraged as a common control or external service, but it is not part of this system's boundary. Including it would incorrectly expand the scope and require assessing controls that are the responsibility of another system owner.

The backup tapes stored offsite at a commercial storage facility.

Why it fails: Backup tapes stored offsite are part of the system's data backup and recovery processes, but they are often considered part of the system's supporting infrastructure or a common control. The storage facility itself is not within the authorization boundary unless the system owner has direct control and responsibility for its security. Typically, offsite storage is covered under a separate agreement or as a service.

The Annual Security Awareness Training log.

Why it fails: A training log evidences that personnel completed awareness requirements; it records compliance activity, not the components, interfaces and assets inside an authorisation boundary. It would be correct if the question asked for evidence supporting the RMF awareness and training control.

The Privacy Threshold Analysis (PTA).

Why it fails: A Privacy Threshold Analysis determines whether a privacy impact assessment is required, addressing personally identifiable information handling rather than system scope. It would be correct if the question asked which document screens systems for privacy review under the RMF.

The System Development Life Cycle (SDLC) policy.

Why it fails: An SDLC policy governs how systems are developed and maintained organisation-wide, not which components sit inside a given authorisation boundary. It would be the right artefact when the question asks for the process governing system lifecycle phases during RMF implementation.

Not Categorized

Why it fails: FIPS 199 mandates categorization for all federal information systems.

Low

Why it fails: The overall categorisation takes the highest impact across confidentiality, integrity and availability, so Moderate integrity and availability lift the system above Low. Low would be correct only if all three impact values were Low, which the stem contradicts.

High

Why it fails: High requires at least one impact value rated High, but the stem gives Low confidentiality with Moderate integrity and availability. Selecting High is tempting when treating any Moderate rating as automatically severe, yet FIPS 199 reserves High for a High impact in at least one security objective.

The Lead System Administrator.

Why it fails: A lead system administrator operates and maintains the system but does not own the information or the mission it supports, so cannot accept the impact rating FIPS 199 requires. Administrators are tempting because they know the technical configuration best, yet categorisation authority belongs to the system owner, who is accountable for the data.

The Chief Information Security Officer (CISO).

Why it fails: The CISO sets security policy and advises on risk, but FIPS 199 categorisation is an authorisation decision resting with the system owner, who is accountable for the information and mission. Involving the CISO is tempting because security oversight feels authoritative, yet sign-off must come from the owner who accepts the resulting impact level.

The Third-Party Auditor.

Why it fails: A third-party auditor performs independent assessment of controls; it does not own the system's data or mission, so it cannot accept the impact-level determination that FIPS 199 categorisation represents. Auditors are tempting because they validate security documentation, but authorisation to categorise rests with the system owner, who is accountable for the information.

To ensure they are manually tested for every individual system.

Why it fails: Common controls are assessed once by the providing organisation and inherited, so per-system manual testing duplicates effort. Identifying them is tempting because assurance matters, but the mechanism is inheritance of assessment results, not repeated testing. The correct purpose is to reduce redundant assessment and documentation across systems sharing those controls.

To increase the system's FIPS 199 impact level.

Why it fails: Common controls are inherited by multiple systems and documented once; they do not alter a system's FIPS 199 impact level, which derives from the confidentiality, integrity and availability categorisation of the information processed. Identifying them is tempting because it streamlines authorisation, but impact level is set by data sensitivity, not control inheritance.

To exclude them from the System Security Plan (SSP).

Why it fails: Common controls are referenced within the SSP, not excluded from it; the SSP documents how inherited controls apply to the system. Identifying them is tempting because it avoids duplicating documentation across systems, but the purpose is to record inheritance and responsibility, not to remove them from the plan.

Include only the database tier.

Why it fails: Restricting the boundary to the database tier omits the interfaces and services the subsystem depends on, leaving integration points ungoverned. Database-only scoping suits a standalone data store, not a subsystem within a system of systems.

Include the entire enterprise infrastructure to be safe.

Why it fails: Including the entire enterprise infrastructure dissolves the sub-system boundary, so the authorisation boundary cannot be scoped, documented or assessed against a defined set of controls. It is tempting because enterprise-wide boundaries suit single-system accreditations, where one authorisation package covers all interconnected components under one security categorisation.

Include all internal network segments regardless of use.

Why it fails: Including every internal network segment regardless of use expands the boundary beyond the sub-system's actual function, so interfaces and dependencies multiply and scope creep follows. Segmentation by function defines the boundary. This option would suit mapping an entire enterprise enclave for network inventory, not scoping a single System of Systems sub-system.

The system's latest vulnerability scan report.

Why it fails: A vulnerability scan enumerates software flaws on hosts, not communication paths between systems, so it cannot evidence interconnection inventory. It is tempting because scans do discover live hosts and open ports, and would suit validating exposure of known interconnections rather than identifying them.

The organization's enterprise risk register.

Why it fails: A risk register records identified risks and treatments, not the authoritative inventory of system interconnections required by the SAP. It is tempting because it catalogues organisational exposures, but interconnection inventory belongs in the system inventory and boundary documentation instead.

A listing of all installed software patches.

Why it fails: Patch listings evidence software maintenance status, not the interconnections between systems that the SAP inventory must demonstrate. It is tempting because patch data supports other assessment objectives, but it cannot show which systems connect to which external or internal counterparts.

Exclude the system from FIPS 199 requirements.

Why it fails: FIPS 199 applies to all federal information systems; no system is exempt because its data is public. Exemption is tempting because publicly available data suggests no confidentiality impact, and would fit a system outside FIPS 199's scope, such as a privately owned system not supporting federal operations.

Categorize only based on Confidentiality.

Why it fails: FIPS 199 requires separate ratings for confidentiality, integrity and availability; categorising on confidentiality alone omits the catastrophic availability impact. Focusing on confidentiality is tempting because the data is public, and would be correct only where availability and integrity losses are negligible.

Confidentiality=Low, Integrity=Low, Availability=Low.

Why it fails: Availability must be rated High because catastrophic loss of a critical service is the FIPS 199 definition of high impact; Low contradicts the stated outage consequence. Rating all three Low is tempting when data is public, and would be correct only if confidentiality, integrity and availability losses were all limited.

Increased cost of hardware procurement.

Why it fails: Hardware procurement cost is unrelated to boundary definition; an inaccurate boundary misstates which systems, people and data fall inside the accreditation scope, leaving controls unassessed and residual risk unaccepted. Procurement budgeting is tempting because boundaries do affect asset inventories, but cost accounting is the concern of financial planning, not the CGRC risk objective.

Violation of the System Development Life Cycle (SDLC).

Why it fails: An inaccurate boundary does not breach SDLC process requirements; it causes systems or data to be assessed outside their authorised scope, leaving components unassessed and controls unapplied. SDLC alignment is a separate governance concern, not the primary risk here.

Inability to perform annual performance reviews.

Why it fails: Annual performance reviews concern staff management, not system authorisation scope. An inaccurate boundary means components are omitted from assessment, so their controls and risks go unmanaged; performance appraisal capability is unaffected by how the boundary is drawn.

NIST SP 800-37.

Why it fails: SP 800-37, the Risk Management Framework, describes how categorisation fits into the authorisation lifecycle but does not itself define the FIPS 199 impact levels or the categorisation method. It is tempting because it governs the overall process, and it would be correct when asked which publication describes the RMF steps.

NIST SP 800-53.

Why it fails: SP 800-53 catalogues security and privacy controls for federal information systems; it does not define the categorisation process. FIPS 199 itself specifies the impact-level categorisation of information types. SP 800-53 is tempting because it is the central control publication, and it would be the correct reference when selecting controls after categorisation.

FIPS 140-3.

Why it fails: FIPS 140-3 specifies security requirements for cryptographic modules, an entirely different subject from information categorisation. It is tempting because it is a FIPS publication, and it would be correct when the question concerns validating cryptographic module implementations.

Force the service provider to sign a full system authorization for you.

Why it fails: A provider cannot transfer its authorisation to you; each system's authorisation remains with its own authorising official. The shared service is documented as an external dependency relying on the provider's existing authorisation. Requesting a signed authorisation would be relevant only if the provider lacked any authorisation covering the service.

The identity service must be fully assessed as part of your system.

Why it fails: A shared identity service sits outside the system's authorization boundary as an external, separately authorised dependency; absorbing it forces you to assess controls you do not own. Documenting it as an external service with its own authorisation is correct. Full inclusion would apply only to components you operate within your boundary.

Exclude the identity service from the documentation entirely.

Why it fails: Omitting the identity service leaves the boundary diagram and dependency description incomplete, so assessors cannot evaluate inherited controls or interconnection risk. The service must be documented as an external dependency. Exclusion would only be defensible for components with no connection to the system whatsoever.

Categorizing each site as a separate information system.

Why it fails: Treating each site as a separate information system fragments authorisation, so no single boundary or control baseline spans the locations. It tempts because separate categorisation simplifies per-site assessment, and would be right if the sites truly operated independently rather than forming one complex boundary.

Excluding remote offices from the authorization boundary.

Why it fails: Excluding remote offices leaves their systems outside the authorisation boundary, so they escape the shared controls and consistency breaks down. It tempts because narrowing scope reduces documentation and assessment effort, and would be valid only where those offices genuinely hold no data or connectivity tied to the system.

Allowing each site to define its own unique security policy.

Why it fails: Per-site policies produce divergent controls across the boundary, defeating the consistency the scenario demands. It tempts because local autonomy respects differing regulations and operational realities at each location, and would be defensible where sites are genuinely independent systems with no shared authorisation boundary.

The Incident Response Policy.

Why it fails: The Incident Response Policy governs how breaches are handled and does not feed the categorisation step. It would be the right artefact when defining detection, containment and reporting procedures, not when establishing impact level from FIPS 199 information types.

The Penetration Test Report.

Why it fails: A penetration test report documents exploitable weaknesses found during security testing, so it cannot authorise system categorisation or initiate the RMF. It is tempting because penetration testing validates controls during the Assess step, and would be the right artefact when evidence of adversarial resilience is required after implementation.

The Contingency Plan.

Why it fails: A Contingency Plan documents recovery procedures for a system already within the RMF, so it cannot finalise categorisation or initiate the process. It is tempting because contingency planning is a genuine RMF step, and would be the right artefact when addressing recovery requirements during the later Select and Implement phases, not at categorisation.