Skip to main content
Control Institute
Category: Control Types and Framework

Baseline Controls

Also known as: Control Baseline, Security Control Baseline, Security Baseline Controls
Simply put

Baseline controls are a predefined starting set of security safeguards that a system is expected to have in place to meet legal, regulatory, or policy requirements. Rather than building protections from scratch, organizations begin from this common set and then adjust it to fit their specific systems and risks. The exact controls in a baseline vary depending on the framework used and how sensitive the system is.

Formal definition

A control baseline is the set of controls applicable to information or an information system, selected to satisfy legal, regulatory, or policy requirements and to address identified security and privacy needs. In the NIST context, SP 800-53B defines three security control baselines corresponding to low-, moderate-, and high-impact information systems, along with a separate privacy baseline; these represent a minimum set of controls that organizations typically tailor based on impact level, mission, and risk. Baselines serve as a starting point for selection rather than a fixed final control set, and the specific controls included depend on the framework and edition referenced. Note that these NIST baselines are distinct from the SOC 2 Trust Services Criteria and from ISO/IEC 27001 Annex A reference controls, which are selected through their own respective processes.

Why it matters

Baseline controls give organizations a defensible, standardized starting point for securing information systems rather than requiring teams to design safeguards from scratch for every system. This matters because ad hoc control selection tends to produce inconsistent coverage, where some systems are heavily protected while others carry unaddressed gaps. By beginning from a predefined baseline aligned to a framework and an impact level, organizations can demonstrate to auditors, regulators, and stakeholders that a considered minimum set of protections was applied and then adjusted deliberately.

Baselines also support the tailoring process that is central to modern risk management. In the NIST context, the low-, moderate-, and high-impact baselines defined in SP 800-53B, along with the separate privacy baseline, let organizations scale the rigor of their controls to the sensitivity and criticality of the system in question. This helps direct effort and resources toward higher-impact systems while avoiding overengineering lower-impact ones, and it creates a traceable rationale for why particular controls were included or excluded.

It is important to recognize the limits of what a baseline provides. A baseline represents a minimum starting point rather than a guarantee of security or a complete control set; implementing a baseline does not by itself ensure freedom from breaches, and controls typically require tailoring based on impact level, mission, and identified risk. NIST baselines are also distinct from the SOC 2 Trust Services Criteria and from ISO/IEC 27001 Annex A reference controls, each of which is selected through its own separate process, so satisfying a NIST baseline does not automatically satisfy those frameworks.

Who it's relevant to

Compliance and GRC Managers
Those responsible for meeting legal, regulatory, or policy requirements use baselines as a defensible starting point for control selection and to document the rationale behind included and excluded controls. They should note that a baseline is a minimum starting point subject to tailoring, and that NIST baselines are distinct from SOC 2 and ISO/IEC 27001 control sets.
Security Engineers and System Owners
Practitioners implementing controls rely on the baseline aligned to a system's impact level as an initial specification, then tailor it based on the system's mission and identified risks. Because the specific controls depend on the framework and edition referenced, they need to confirm which baseline and version applies before implementation.
Auditors and Assessors
Those evaluating control environments use the selected baseline and the organization's tailoring decisions to assess whether an appropriate minimum set of protections was applied for the system's impact level. They should treat the baseline as evidence of a starting point rather than proof of complete or breach-proof security.
Risk Management Teams
Teams performing impact analysis map systems to low-, moderate-, or high-impact levels to determine which baseline applies, then guide tailoring so that control rigor is proportionate to sensitivity and risk. This helps focus resources on higher-impact systems while maintaining a documented justification for control choices.

Inside Baseline Controls

Baseline Control Set
A predefined collection of security controls that an organization adopts as its minimum starting point across systems or environments. In SOC 2 engagements these controls are mapped to the applicable Trust Services Criteria; in ISO 27001, baseline controls are typically drawn from Annex A reference controls and selected via the Statement of Applicability informed by risk assessment.
Risk-Informed Selection
The process by which baseline controls are chosen or adjusted based on the organization's risk assessment, scope, and applicable criteria. Under ISO 27001, Annex A controls are reference controls selected in light of identified risks rather than applied wholesale; the specific controls depend on the ISMS scope.
Framework Mapping
The alignment of a baseline to one or more frameworks, such as the SOC 2 Common Criteria (Security) plus any optional categories, or ISO 27001 clauses 4 through 10 and selected Annex A controls. Mapping between frameworks is possible but typically partial, so a single baseline rarely satisfies all frameworks equally.
Scope Boundaries
The systems, services, and environments to which the baseline applies. Baseline controls attest to or cover only the defined scope; controls outside the boundary are not addressed by the baseline in either a SOC 2 report or an ISO 27001 certificate.
Tailoring and Exceptions
Documented deviations from the baseline where a control is added, removed, or modified for a specific environment. In ISO 27001 this rationale is typically captured in the Statement of Applicability; in SOC 2 the design of controls is described relative to the criteria being addressed.

Common questions

Answers to the questions practitioners most commonly ask about Baseline Controls.

Does establishing baseline controls mean I've satisfied both SOC 2 and ISO 27001 at once?
No. A common set of baseline controls can support both frameworks, but satisfying one does not automatically satisfy the other. SOC 2 is an attestation examination performed by a licensed CPA firm against the AICPA Trust Services Criteria, resulting in a report, while ISO/IEC 27001 is a certification issued by an accredited certification body against the ISMS requirements in clauses 4 through 10, with Annex A controls selected via a Statement of Applicability. Mapping between the two is possible but only partial, so baseline controls typically need to be assessed separately against each framework's requirements and scope.
Are baseline controls a fixed, mandatory list that every organization must implement identically?
Not generally. Outside of the specific requirements each standard imposes, there is no single universal list of mandatory baseline controls. In most engagements the appropriate baseline depends on scope, risk assessment, applicable criteria, and decisions made with the auditor or certification body. For ISO 27001, Annex A functions as a reference set of controls selected through the Statement of Applicability and informed by risk assessment rather than an obligatory checklist applied identically everywhere. For SOC 2, the Security category (Common Criteria) is required while Availability, Processing Integrity, Confidentiality, and Privacy are optional and selected based on scope.
How do baseline controls relate to a SOC 2 Type I versus a Type II examination?
In a SOC 2 Type I, baseline controls are assessed for suitability of design at a point in time, so the focus is on whether the controls are appropriately designed. In a Type II, the same baseline controls are assessed for both design and operating effectiveness over a defined review period, meaning you typically need evidence that the controls operated consistently throughout that period. The length of the period is set by scoping decisions rather than being fixed, so baseline controls should be maintained and documented with that in mind.
How do I decide which baseline controls to include in scope?
Scoping decisions typically drive the selection. For ISO 27001, controls are selected via the Statement of Applicability and informed by the risk assessment, and Annex A serves as a reference set to consider. For SOC 2, the Security Common Criteria is required, and you add controls supporting Availability, Processing Integrity, Confidentiality, or Privacy only if those categories are within scope. In most engagements the final set is refined in coordination with the auditor or certification body based on the systems, services, and criteria being covered.
What evidence should I retain to demonstrate baseline controls are in place?
The evidence expected depends on the framework and the type of assessment. For a SOC 2 Type I, documentation demonstrating suitable design at a point in time is typically sufficient, whereas a Type II generally requires evidence that controls operated effectively across the review period. For ISO 27001, evidence usually supports the ISMS requirements in clauses 4 through 10 and the controls recorded in the Statement of Applicability. In all cases, the specific evidence expectations vary by auditor, certification body, and scope.
Do baseline controls guarantee my organization won't experience a breach?
No. Baseline controls reduce risk but do not guarantee freedom from security incidents. A SOC 2 report attests only to the controls and period covered and does not guarantee an organization is breach-free, and an ISO 27001 certificate covers only the defined scope of the ISMS. Baseline controls should therefore be understood as risk-management measures assessed within a defined boundary rather than an assurance against all possible compromise.

Common misconceptions

Adopting a baseline control set means the organization is automatically compliant with SOC 2 or ISO 27001.
A baseline is a starting point, not an outcome. A SOC 2 report requires an examination by a licensed CPA firm under SSAE 18 attesting to the design (Type I) or design and operating effectiveness (Type II) of controls, while ISO 27001 requires certification by an accredited certification body against the ISMS requirements. Having baseline controls in place does not by itself produce either result.
A single baseline satisfies both SOC 2 and ISO 27001 at once.
Mapping between the frameworks is possible but partial. The SOC 2 Trust Services Criteria are not the same as ISO 27001 Annex A reference controls, and satisfying one framework does not automatically satisfy the other. A baseline may serve as common ground, but framework-specific gaps typically remain and depend on scope and applicable criteria.
Every control in a published baseline is mandatory.
Control applicability generally depends on the organization's risk assessment, scope, and the criteria in play. Under ISO 27001, Annex A controls are selected via the Statement of Applicability and may be excluded with justification; under SOC 2, only the Security (Common Criteria) category is required, with other categories selected based on scope. Few individual controls are universally mandatory unless the standard itself requires them.

Best practices

Anchor your baseline to a documented risk assessment and scope definition so that control selection is justified rather than arbitrary, particularly for ISO 27001 where the Statement of Applicability records inclusions and exclusions.
Clearly identify which framework or criteria each baseline control supports, keeping the SOC 2 Trust Services Criteria distinct from ISO 27001 Annex A reference controls to avoid conflating the two.
Define and document the systems and environments covered by the baseline, since coverage is limited to the defined scope in both a SOC 2 report and an ISO 27001 certificate.
Record tailoring decisions and exceptions with rationale, so that additions, removals, or modifications to the baseline are traceable during an examination or certification audit.
Treat the baseline as a starting point that still requires validation through the appropriate process, whether a CPA firm's SSAE 18 examination for SOC 2 or an accredited certification body assessment for ISO 27001.
Where you intend a baseline to support multiple frameworks, map controls explicitly and expect partial overlap, planning for framework-specific gaps rather than assuming one baseline satisfies all frameworks.