Skip to main content
Control Institute
Category: Audit Process

Control Design

Also known as: Design of Controls, Suitability of Design
Simply put

Control design is the process of developing and structuring internal controls so they are capable of preventing errors, detecting irregularities, and supporting reliable operations. In a compliance context, a well-designed control is one that, if it operates as intended, would meet the objective it is meant to address. Designing a control well does not by itself prove that the control actually works over time; that is a separate question of operating effectiveness.

Formal definition

Control design refers to the development and structuring of internal controls intended to prevent, detect, or correct errors and irregularities in support of a defined control objective, and is typically assessed as part of risk management processes. In a SOC 2 examination, the suitability of design of controls is evaluated in both Type I and Type II reports: a Type I report assesses whether controls are suitably designed to meet the applicable Trust Services Criteria as of a point in time, while a Type II report assesses suitability of design in addition to operating effectiveness over a review period whose length is determined by scoping decisions. Evaluating design suitability considers whether a control, assuming it operated as described, would achieve its stated objective; it does not on its own establish that the control operated effectively, nor does a favorable design conclusion guarantee freedom from breaches. In an ISO/IEC 27001 context, control selection and design are informed by risk assessment and documented in the Statement of Applicability, drawing on Annex A reference controls; the specifics vary by scope, framework, and the assessing auditor or certification body.

Why it matters

Control design sits at the foundation of any compliance effort because a control that is poorly conceived cannot achieve its objective no matter how diligently it is performed. If the underlying design is flawed, the control may operate exactly as documented and still fail to prevent, detect, or correct the errors and irregularities it was meant to address. This is why design is evaluated as a distinct question from whether a control actually works over time: a well-designed control is one that, assuming it operated as intended, would meet its stated objective.

In a SOC 2 examination, suitability of design is assessed in both Type I and Type II reports. A Type I report evaluates whether controls are suitably designed to meet the applicable Trust Services Criteria as of a point in time, while a Type II report assesses suitability of design in addition to operating effectiveness over a review period whose length is determined by scoping decisions. Because these are separate conclusions, a favorable design assessment does not by itself establish that a control operated effectively, and it does not guarantee freedom from breaches. Organizations that treat design and operating effectiveness as the same thing risk misreading what a report actually attests to.

Control design is also central to risk management more broadly. Controls should be developed and structured in response to identified risks so that the design directly addresses the exposures that matter to the organization. In an ISO/IEC 27001 context, control selection and design are informed by risk assessment and documented in the Statement of Applicability, drawing on Annex A reference controls. The specifics vary by scope, framework, and the assessing auditor or certification body, so design decisions are best understood as scope-dependent rather than universal.

Who it's relevant to

Compliance and GRC Managers
Compliance and GRC professionals rely on sound control design to ensure that controls actually map to identified risks and to the objectives they are meant to satisfy. Because design is a separate question from operating effectiveness, they need to confirm that a control would meet its objective if performed as described before worrying about how consistently it runs.
SOC 2 Auditors and CPA Firms
Auditors assess suitability of design as a distinct conclusion in both Type I and Type II reports, evaluating whether controls are designed to meet the applicable Trust Services Criteria. They must be careful to communicate that a favorable design conclusion does not establish operating effectiveness or guarantee freedom from breaches.
ISO 27001 Practitioners
Those building or maintaining an ISMS use risk assessment to inform control selection and design, documenting the outcome in the Statement of Applicability with reference to Annex A controls. The specific controls chosen depend on the defined scope and the certification body assessing the management system.
Security Engineers and Control Owners
Engineers who implement and operate controls benefit from understanding the design intent behind them, since a control performed exactly as documented can still fail if the underlying design does not address the relevant risk. Clarity on design objectives helps them build controls that are capable of meeting their stated purpose.

Inside Control Design

Control Objective
The intended outcome a control is meant to achieve, such as restricting access to authorized users or ensuring changes are reviewed before deployment. Control design begins by articulating what risk the control addresses.
Suitability of Design
The assessment of whether a control, if operating as intended, would achieve its stated objective. In a SOC 2 Type I examination, a licensed CPA firm evaluates suitability of design at a point in time; a Type II examination evaluates both design and operating effectiveness over a defined review period whose length is set by scoping decisions.
Control Activity Specification
The concrete description of who performs the control, what action is taken, how frequently, and against what criteria. Well-designed controls specify these attributes so that operating effectiveness can later be tested.
Alignment with Criteria
The linkage between a control and the framework requirement it supports. Under SOC 2, controls are mapped to the applicable Trust Services Criteria, where Security (the Common Criteria) is required and Availability, Processing Integrity, Confidentiality, and Privacy are optional depending on scope. Under ISO 27001, controls are selected via the Statement of Applicability, informed by risk assessment and referencing Annex A.
Risk-Informed Selection
The basis on which controls are chosen. In an ISO 27001 ISMS, the requirements in clauses 4 through 10 drive a risk assessment that informs which Annex A reference controls are applicable; the design of each selected control should trace back to an identified risk.

Common questions

Answers to the questions practitioners most commonly ask about Control Design.

Does a SOC 2 Type I report confirm that my controls are actually working?
No. A SOC 2 Type I engagement assesses only the suitability of the design of controls at a specific point in time. It evaluates whether controls, as designed, would be capable of meeting the applicable Trust Services Criteria if they operated as intended. It does not test operating effectiveness over a period, which is the focus of a Type II engagement. Well-designed controls can still fail in practice, so a Type I result should not be read as evidence that controls performed effectively.
Is control design the same thing under SOC 2 and ISO 27001?
Not exactly. While both frameworks care about whether controls are appropriately designed, they approach it through different structures. Under SOC 2, design is evaluated against the Trust Services Criteria, with Security (the Common Criteria) required and other categories selected by scope. Under ISO 27001, the certifiable requirements sit in clauses 4 through 10, and Annex A provides reference controls selected via a Statement of Applicability informed by risk assessment. Mapping between the two is possible but partial, and demonstrating sound control design in one framework does not automatically satisfy the other.
How do I demonstrate that a control is suitably designed for a SOC 2 examination?
In most engagements, you show the relationship between the control and the specific Trust Services Criteria it is intended to address, and you provide evidence that the control, if operating as described, would meet that criterion. This typically includes documented policies or procedures, a clear description of the control activity, the responsible owner, and the intended frequency. The service auditor evaluates whether the design is appropriate for the stated objective. The exact evidence expected depends on the auditor, the scope, and the applicable criteria.
Where does control design fit in the ISO 27001 process?
Control design in an ISO 27001 context typically follows risk assessment. Based on identified risks, an organization selects applicable Annex A reference controls and documents them, along with justifications for inclusion or exclusion, in the Statement of Applicability. The design should reflect how each selected control treats the associated risk. Because Annex A was restructured in the 2022 revision, organizations should confirm which edition they are working against when documenting control selection and design.
What is the difference between a control being well-designed and a control being effective?
Design refers to whether a control is appropriately structured to meet its objective, while effectiveness refers to whether the control actually operated as intended over time. Under SOC 2, a Type I engagement addresses design at a point in time, whereas a Type II engagement addresses both design and operating effectiveness over a defined review period whose length is set by scoping decisions. A control can be well-designed on paper yet fail in operation, which is why operating effectiveness is assessed separately.
How do I document control design so it holds up during an audit or certification assessment?
Documentation typically describes the control objective, the specific activity performed, the control owner, the intended frequency, and how the control links to the relevant criteria or risk. For SOC 2, this ties back to the applicable Trust Services Criteria; for ISO 27001, it ties back to the risk assessment and Statement of Applicability. Clear, consistent documentation helps the auditor or certification body evaluate design. Keep in mind that neither a SOC 2 report nor an ISO 27001 certificate guarantees freedom from breaches, and each covers only the controls, period, or ISMS scope defined in the engagement.

Common misconceptions

A well-designed control guarantees the outcome will be achieved in practice.
Control design addresses suitability of design only, whether a control would achieve its objective if it operated as intended. Whether it actually operates effectively over time is a separate matter, evaluated in a SOC 2 Type II examination or through ISMS monitoring. Sound design does not, by itself, guarantee freedom from breaches.
The same control design satisfies both SOC 2 and ISO 27001 automatically.
Mapping between the two frameworks is possible but partial. SOC 2 controls align with the Trust Services Criteria under a CPA attestation, while ISO 27001 controls are selected through a Statement of Applicability under an accredited certification body. Designing a control for one framework does not automatically satisfy the other, and the Trust Services Criteria are not equivalent to Annex A controls.
There is a fixed, mandatory set of controls every organization must design.
Control selection typically depends on scope, risk, applicable criteria, and the judgment of the auditor or certification body. For SOC 2, only the Security category is required; for ISO 27001, Annex A controls are reference controls selected via risk assessment rather than a mandatory checklist. Few controls are universally required unless the standard itself demands them.

Best practices

Document each control's objective and trace it to the specific requirement it supports, an applicable Trust Services Criterion for SOC 2 or an entry in the Statement of Applicability for ISO 27001.
Specify control attributes explicitly (owner, action, frequency, and evaluation criteria) so that suitability of design can be assessed and operating effectiveness can later be tested.
Ground control selection in a documented risk assessment, particularly for an ISO 27001 ISMS where clauses 4 through 10 drive which Annex A reference controls are applicable.
Define scope clearly before designing controls, recognizing that a SOC 2 report attests only to the controls and period covered and that an ISO 27001 certificate covers only the defined ISMS scope.
When pursuing both frameworks, treat any mapping between SOC 2 and ISO 27001 as partial, and validate each control against both sets of requirements rather than assuming equivalence.
Engage the CPA firm or certification body early on scoping decisions, since control design expectations typically vary by auditor, criteria selected, and applicable version of the standard.