Skip to main content
Control Institute
Category: Audit Process

Test of Design

Also known as: TOD, Test of Design (TOD), Suitability of Design Testing, Design Effectiveness Testing
Simply put

A Test of Design is an evaluation that checks whether a control is set up in a way that could actually prevent or detect the errors or problems it is meant to address. It looks at how the control is structured and whether it would work as intended if operated correctly, rather than whether it has been operating over time. In a SOC 2 context, this type of assessment underpins what a Type I examination reports on at a single point in time.

Formal definition

A Test of Design (TOD) is a control evaluation procedure that assesses whether a control, as designed and implemented, is suitably structured to prevent or to detect and correct the errors, misstatements, or policy failures within its stated objective. It typically involves inquiry, inspection of relevant documentation, and walkthroughs to understand the control's design and confirm it has been placed in operation. In SOC 2 engagements performed under the AICPA SSAE 18 standard, evaluating the suitability of design at a point in time is characteristic of a Type I examination, whereas a Type II examination assesses both design suitability and operating effectiveness over a defined review period. A Test of Design does not, on its own, provide evidence that the control operated effectively over time; that is the purpose of a separate test of operating effectiveness. Conclusions may vary depending on the scope, the criteria applied, and the practitioner's judgment.

Why it matters

A Test of Design is foundational because a control that is poorly conceived cannot be relied upon no matter how diligently it is operated. If a control is structured in a way that could never actually prevent or detect the errors it targets, then evidence of it running repeatedly is of little value. For this reason, evaluating the suitability of design is typically treated as the first step in assessing internal controls, establishing whether the control is even worth testing for operating effectiveness.

In a SOC 2 context, the Test of Design underpins what a Type I examination reports on: the suitability of design of controls at a single point in time. This distinction matters to report readers because a Type I report speaks only to whether controls were appropriately designed and placed in operation as of a specified date, not to whether they operated effectively over a period. A user relying on a Type I report should understand that a favorable design conclusion does not demonstrate sustained operation, which is instead the purpose of the operating effectiveness testing characteristic of a Type II examination.

Understanding these boundaries helps organizations and report users avoid overreliance. A Test of Design does not, on its own, provide assurance that a control functioned as intended throughout a review period, and conclusions may vary depending on the scope, the criteria applied, and the practitioner's judgment.

Who it's relevant to

Compliance and GRC Managers
For those coordinating a SOC 2 examination, understanding the Test of Design clarifies what a Type I report will and will not cover. It helps set expectations with stakeholders that a favorable design conclusion at a point in time does not demonstrate sustained operating effectiveness, which is addressed only in a Type II examination over a defined review period.
Auditors and Practitioners
For CPA firms and internal auditors, the Test of Design is typically the first step in control evaluation, carried out through inquiry, inspection of documentation, and walkthroughs. Practitioners must exercise judgment in concluding whether a control is suitably structured to meet its stated objective, recognizing that conclusions may vary depending on scope and the criteria applied.
Security Engineers and Control Owners
For those who build and maintain controls, a Test of Design signals whether a control is structured to actually address the errors or policy failures it targets before it is assessed for how it operates over time. It highlights that a well-designed control is a prerequisite, not a substitute, for demonstrating operating effectiveness.
Report Users and Customers
For those relying on a SOC 2 report to assess a service organization, understanding the Test of Design helps interpret a Type I report correctly. Such a report attests only to the suitability of design at a point in time and does not, on its own, provide evidence that controls operated effectively or guarantee freedom from breaches.

Inside TOD

Suitability of Design Evaluation
A test of design assesses whether a control, if operating as described, would be capable of meeting the applicable criteria or control objective. It focuses on how the control is intended to work rather than whether it operated effectively over time.
Point-in-Time Focus
In a SOC 2 examination, the test of design is central to a Type I report, which evaluates the suitability of the design of controls as of a specified point in time rather than across a review period.
Relationship to Operating Effectiveness
A test of design is distinct from a test of operating effectiveness. Design testing asks whether the control is properly conceived to address a risk; operating effectiveness testing, central to a SOC 2 Type II examination, asks whether the control actually functioned as intended over a defined period. A control can be well-designed yet fail in operation.
Inputs to the Assessment
Evaluating design typically involves reviewing control descriptions, understanding the underlying risk the control addresses, and considering whether the control, as documented, aligns with the relevant Trust Services Criteria (in SOC 2) or the risk-based controls selected via the Statement of Applicability (in an ISO 27001 context).
Cross-Framework Applicability
The concept of assessing control design appears in both frameworks, though the terminology and mechanics differ. In SOC 2 it is performed by a licensed CPA firm under SSAE 18; in ISO 27001 the adequacy of control design is considered by an accredited certification body as part of evaluating the ISMS and selected Annex A reference controls.

Common questions

Answers to the questions practitioners most commonly ask about TOD.

Does passing a test of design mean my controls are actually working?
No. A test of design evaluates whether a control, if operating as described, would be capable of meeting the relevant criterion or objective. It assesses suitability of design at a point in time, not whether the control operated effectively over a period. Evaluating operating effectiveness requires tests of operating effectiveness, which in a SOC 2 context are performed in a Type II examination over a defined review period rather than a Type I. A well-designed control can still fail in practice if it is not consistently performed.
Is a test of design the same thing across SOC 2 and ISO 27001?
The underlying concept, assessing whether a control is designed appropriately to address a risk or criterion, appears in both frameworks, but the context differs and the frameworks should not be conflated. In a SOC 2 examination, a CPA firm evaluates the suitability of design of controls against the applicable Trust Services Criteria under the AICPA's attestation standard. In ISO/IEC 27001, the adequacy of controls is considered as part of the ISMS requirements in clauses 4 through 10 and the selection of Annex A reference controls via the Statement of Applicability, informed by risk assessment. Satisfying a design evaluation in one framework does not automatically satisfy the other.
What evidence is typically reviewed during a test of design?
In most engagements, evidence may include policies and procedures, system configurations, process documentation, control descriptions, and inquiry with control owners, often supplemented by observation or inspection of how a control is intended to function. The specific evidence depends on the auditor, the scope, and the nature of the control. Because a test of design focuses on suitability of design rather than operation, the emphasis is on whether the control as constructed would address the applicable criterion, not on a sample of operating instances over time.
When would an organization pursue a test of design rather than a test of operating effectiveness?
Organizations often rely primarily on design evaluation when controls are newly implemented and have not yet operated for a sufficient period to demonstrate effectiveness, or when the objective is to establish that controls are appropriately designed before committing to an examination covering operation over time. In a SOC 2 context this typically aligns with a Type I examination, which assesses suitability of design at a point in time. Scoping decisions, timing, and the intended audience of the report generally drive this choice.
How does a deficiency identified in a test of design get handled?
When a control is found not to be suitably designed to address the applicable criterion, the practitioner typically documents the design gap and the organization may remediate by revising or adding controls before the assessment concludes, depending on timing and scope. The treatment and how it is reflected in the outcome depend on the auditor's judgment and the framework involved. A design deficiency is distinct from an operating deficiency, and the two are evaluated separately.
What are the limitations of relying on a test of design?
A test of design speaks only to whether controls are suitably designed at a point in time within the defined scope; it does not confirm that controls operated effectively over any period, and it does not guarantee freedom from breaches or security incidents. Assurance over operation typically requires testing of operating effectiveness over a defined review period. Any conclusion is also bounded by the controls and criteria within scope, so it should not be read as a broader statement about the organization's overall security posture.

Common misconceptions

A successful test of design means the controls are working effectively.
A test of design only evaluates whether a control is suitably designed to meet its objective if operated as intended. It does not confirm that the control actually operated effectively; that requires a separate test of operating effectiveness, which in SOC 2 is characteristic of a Type II examination performed over a defined period.
A test of design covers a period of time.
In a SOC 2 context, a test of design underpins a Type I report, which assesses suitability of design as of a point in time. Assessment over a review period, with the length set by scoping decisions, is associated with Type II operating-effectiveness testing rather than design testing alone.
Passing a test of design guarantees the organization is free from breaches or gaps.
A test of design attests only to whether the controls in scope are designed to meet the applicable criteria. It does not guarantee freedom from breaches, and any resulting SOC 2 report attests only to the controls and period covered, while an ISO 27001 certificate covers only the defined scope of the ISMS.

Best practices

Clearly document each control's objective and the specific risk or applicable criterion it is intended to address, so its design can be evaluated against a defined purpose.
Distinguish design testing from operating-effectiveness testing in planning and reporting, recognizing that a Type I report addresses suitability of design at a point in time while a Type II addresses design and operating effectiveness over a scoped period.
Map controls to the relevant framework requirements, such as the Trust Services Criteria for SOC 2 or the Annex A controls selected through the Statement of Applicability for ISO 27001, keeping in mind that mapping between the two frameworks is only partial.
Confirm the version of the standard being referenced when discussing control coverage, since Annex A control counts differ between the 2013 and 2022 revisions of ISO 27001.
Retain the control descriptions, risk assessments, and supporting documentation that evidence why a control is suitably designed, since these inputs support the assessor's evaluation.
Communicate to stakeholders that a favorable design evaluation confirms only how controls are intended to work and does not, on its own, assure ongoing operating effectiveness or freedom from incidents.