Skip to main content
Control Institute
Category: Risk Assessment and Treatment

Control Baseline Selection

Also known as: Baseline Control Selection, Baseline Selection Approach
Simply put

Control baseline selection is the practice of choosing a pre-defined set of security and privacy controls as a starting point for protecting an information system. Rather than building a control set from scratch, an organization picks a baseline matched to how sensitive or critical the system is, then adjusts it to fit its specific circumstances. This gives teams a consistent, repeatable foundation for managing information security and privacy risk.

Formal definition

Control baseline selection is the baseline control selection approach described in NIST guidance, in which practitioners select a pre-defined set of controls (a control baseline) assembled to address a defined level of protection. Under NIST SP 800-53B, there are three security control baselines corresponding to low-, moderate-, and high-impact system categorizations, along with a privacy baseline for systems subject to privacy considerations. The selected baseline is not applied verbatim; it is subsequently tailored (per NIST SP 800-53 control PL-11) by identifying and designating common controls, applying scoping considerations, and selecting compensating controls as needed to reflect the organization's risk environment and operational context. This NIST-oriented approach is distinct from the SOC 2 Trust Services Criteria and from ISO/IEC 27001 Annex A control selection via a Statement of Applicability, though the underlying concept of risk-informed control selection is broadly analogous.

Why it matters

Control baseline selection matters because it gives organizations a disciplined, repeatable starting point for managing information security and privacy risk rather than assembling a control set from scratch. By matching a pre-defined baseline to how sensitive or critical a system is, teams can achieve consistency across systems and reduce the risk of overlooking foundational safeguards. Under NIST SP 800-53B, the three security baselines corresponding to low-, moderate-, and high-impact categorizations provide a structured way to align the rigor of controls with the consequences of a compromise.

The practice also matters because a baseline is only a starting point, not a finished control set. NIST guidance expects the selected baseline to be tailored to the organization's actual risk environment and operational context. Applying a baseline verbatim without designating common controls, applying scoping considerations, or selecting compensating controls can leave a control set poorly fitted to the system it is meant to protect. The value of baseline selection therefore comes from combining a sound starting point with thoughtful, risk-informed adjustment.

For teams working across multiple frameworks, it is worth noting that this NIST-oriented approach is distinct from the SOC 2 Trust Services Criteria and from ISO/IEC 27001 Annex A control selection via a Statement of Applicability. The underlying concept of risk-informed control selection is broadly analogous across these frameworks, but the specific baselines, control catalogs, and selection mechanisms differ, and satisfying one approach does not automatically satisfy another.

Who it's relevant to

GRC and compliance managers
Compliance managers responsible for aligning systems with NIST SP 800-53 use baseline selection to establish a consistent, repeatable foundation for control implementation across systems of differing impact levels. Understanding the distinction between selecting a baseline and tailoring it helps them document a defensible rationale for the resulting control set.
Security engineers and architects
Engineers and architects translate a selected baseline into implemented controls. They are typically the ones who apply scoping considerations, designate common controls, and identify compensating controls during tailoring, so a clear grasp of the PL-11 tailoring process helps ensure the deployed control set fits the system's operational context.
Professionals mapping across frameworks
Practitioners who work across NIST, SOC 2, and ISO/IEC 27001 should recognize that NIST baseline selection is distinct from the SOC 2 Trust Services Criteria and from ISO 27001 Annex A selection via a Statement of Applicability. The risk-informed concept is broadly analogous, but mappings between frameworks are partial, and using a NIST baseline does not by itself satisfy a SOC 2 examination or ISO 27001 certification.

Inside Control Baseline Selection

Risk Assessment Input
In an ISO/IEC 27001 context, control baseline selection is informed by the results of the risk assessment, which identifies risks the organization must treat. The selected controls should trace back to identified risks rather than being chosen arbitrarily.
Statement of Applicability (SoA)
For ISO/IEC 27001, the Annex A reference controls are selected and justified through the Statement of Applicability, which documents which controls are included, which are excluded, and the rationale for each decision.
Annex A Reference Controls
ISO/IEC 27001 provides Annex A as a set of reference controls to consider during selection. The structure and count differ by edition (the 2013 version listed 114 controls; the 2022 revision restructured these into 93 controls across four themes), so the applicable version should be specified when citing counts.
Trust Services Criteria Scope (SOC 2)
For a SOC 2 examination, the analogous scoping decision is which Trust Services Criteria categories apply. Security (the Common Criteria) is the only required category, while Availability, Processing Integrity, Confidentiality, and Privacy are optional and selected based on the services and commitments in scope.
Scope Boundaries
Baseline selection defines the boundaries of what will be assessed, whether the ISMS scope for ISO/IEC 27001 or the system and criteria covered by a SOC 2 report. Controls and criteria outside these boundaries are not covered by the resulting certificate or report.

Common questions

Answers to the questions practitioners most commonly ask about Control Baseline Selection.

Does ISO 27001 require me to implement every Annex A control as my baseline?
No. Annex A is a list of reference controls, not a mandatory checklist. The certifiable requirements sit in clauses 4 through 10, and the controls you apply are selected through your risk assessment and documented in a Statement of Applicability. You justify which reference controls are applicable, and which are excluded, based on your ISMS scope and risk treatment decisions. Note that the number of Annex A reference controls depends on the edition, the 2022 revision reorganized them into four themes, so specify the version when discussing counts.
Is the SOC 2 Common Criteria the same as an ISO 27001 control baseline?
Not exactly. The Trust Services Criteria (with Security, the Common Criteria, being the only required category) are the basis of a SOC 2 examination, while ISO 27001 uses ISMS clause requirements plus Annex A reference controls selected via a Statement of Applicability. Mapping between the two is possible but partial. Satisfying a SOC 2 baseline does not automatically satisfy an ISO 27001 baseline, or vice versa, because the frameworks structure and evidence their controls differently.
How do I decide which optional Trust Services Criteria to include in my SOC 2 baseline?
Selection typically depends on the scope of the services you provide and the commitments you make to customers. Security (the Common Criteria) is always required, while Availability, Processing Integrity, Confidentiality, and Privacy are optional and chosen based on what is relevant to your system and stakeholder expectations. In most engagements this scoping decision is made in consultation with the service auditor, since the criteria selected define what the resulting report covers.
How does the Statement of Applicability drive my ISO 27001 baseline in practice?
The Statement of Applicability documents which Annex A reference controls you have determined to be applicable, the justification for their inclusion, whether they are implemented, and the justification for any exclusions. In most implementations it is derived from your risk assessment and risk treatment plan, so the baseline reflects your organization's context and risk decisions rather than a fixed universal set. Certification bodies typically review this document to confirm your control selection is consistent with your assessed risks.
Should my control baseline differ between a SOC 2 Type I and a Type II?
The controls you select can be the same, but what is assessed differs. A Type I evaluates the suitability of design of your controls at a point in time, while a Type II evaluates both design and operating effectiveness over a defined review period whose length is set by scoping decisions. This means a Type II baseline generally needs controls that can produce evidence of consistent operation across the period, not just evidence that they were designed appropriately.
Does selecting a strong control baseline guarantee I will pass or avoid a breach?
No. A SOC 2 report attests only to the controls and period covered and does not guarantee freedom from breaches, and an ISO 27001 certificate covers only the defined scope of the ISMS. A well-chosen baseline improves the likelihood of a favorable outcome, but the actual result depends on the auditor or certification body, the scope, the applicable criteria, and how effectively the controls operate. Baseline selection reduces risk but does not eliminate it or serve as a guarantee.

Common misconceptions

An organization must implement every Annex A control to achieve ISO/IEC 27001 certification.
Annex A is a set of reference controls, not a mandatory checklist. Controls are selected and justified through the Statement of Applicability, informed by the risk assessment, and controls may be excluded with documented rationale depending on scope.
Selecting a control baseline for SOC 2 works the same way as for ISO/IEC 27001.
The frameworks scope differently. SOC 2 selection centers on which Trust Services Criteria categories apply (with Security always required), while ISO/IEC 27001 selection centers on risk-driven choice of Annex A reference controls documented in a Statement of Applicability. Mapping between the two is possible but partial, and satisfying one does not automatically satisfy the other.
Once a baseline is selected and certified or reported on, it demonstrates the organization is free from breaches or covers all its systems.
A SOC 2 report attests only to the controls and period covered, and an ISO/IEC 27001 certificate covers only the defined ISMS scope. Neither guarantees freedom from breaches, and anything outside the selected baseline and scope is not covered.

Best practices

Drive ISO/IEC 27001 control selection from the results of the risk assessment so each included control traces back to an identified risk, and document included and excluded controls with justification in the Statement of Applicability.
Specify which edition of ISO/IEC 27001 Annex A you are working against when referencing control counts, since the 2013 and 2022 versions differ in structure and number.
For SOC 2, decide early which Trust Services Criteria categories are in scope, remembering that Security (the Common Criteria) is required and the other categories are optional and selected based on your services and commitments.
Define and document scope boundaries clearly, since the resulting SOC 2 report or ISO/IEC 27001 certificate only covers the controls, criteria, and systems within those boundaries.
Avoid treating a control baseline selected for one framework as automatically satisfying the other; where mapping is used, treat it as partial and validate each requirement independently.
Revisit baseline selection when scope, risk profile, or the applicable standard version changes, rather than assuming an initial selection remains appropriate over time.