Scope of the System
Define the boundary before selecting controls
An authorization boundary includes every component that processes, stores, transmits, or protects the system's data and functions - hardware, software, people, processes, facilities, interconnections, and supporting infrastructure, even when owned by a vendor. Under-scoping leaves real risk unassessed; over-scoping inflates cost and effort. Both are failures.
Categorization drives everything downstream
Using FIPS 199, rate confidentiality, integrity, and availability separately as low, moderate, or high based on the potential impact of compromise. The system's overall category is the high-water mark of the three. Trap: averaging the three impacts, or letting a low confidentiality rating pull down the overall category.
Follow the data
Identify the data types in play - PII, PHI, CUI, financial, cardholder, intellectual property - and map where each is stored, transmitted, processed, and destroyed. Scope follows the data: backups, disaster recovery sites, test and development environments, endpoint devices, mobile access, and printing all count if the data reaches them. Data flow diagrams and boundary diagrams are the tangible evidence of scope decisions.
Interconnections and shared services
Separate common controls (inherited from a parent organization or provider) from system-specific controls; hybrid means partially inherited. Leveraging a provider's authorization does not automatically authorize your system - you must confirm the provider's scope and currency and record the agreement (ISA/MOU). In cloud, apply the shared responsibility model explicitly.
Rule of thumb: if you cannot state where each data element is stored, transmitted, processed, and destroyed, your scope is incomplete - and any control selection built on it is unreliable.
Document scope decisions and their rationale; scope changes must trigger reassessment, not silent expansion.