Control Design: From Regulatory Requirements to Measurable Control Activities

Headline: Don't Write Policies That Describe Actions — Write Controls That Produce Outcomes


The Design Challenge

Many organizations struggle with control design. They create controls that are:

  • Too vague to be operational
  • Too prescriptive to be adaptable
  • Not linked to actual risks
  • Not measurable or testable

The result: Controls that exist on paper but don't operate effectively in practice.

Design Principles

1. Start with Outcomes, Then Design Controls

A common mistake is writing controls that describe actions instead of outcomes .

Weak Approach

Stronger Approach

"Run monthly access reviews"

"Access to sensitive systems is reviewed at a defined cadence, exceptions are documented, and results are retained as evidence"

Outcomes help you adapt controls to different tools and environments .

2. Translate Requirements to Controls

The process of controls management starts with understanding requirements and translating them into controls:

Source

Example

Control Design

Regulation

GDPR Article 32: Security of processing

Implement access controls, encryption, monitoring

Standard

ISO 27001 A.9.1.2: Access to networks and network services

Define access control policy

Policy

"All sensitive data must be protected"

Implement data classification, encryption, access controls

3. Document Technology Dependencies

Management determines the dependency and linkage between business processes, automated control activities, and technology general controls . Using risk and control matrices to document technology dependencies helps :

  • Understand which aspects of technology are important to continued operation of controls
  • Identify how various applications and technologies interface with each other
  • Ensure controls are appropriately implemented and monitored

4. Design for Testability

Every control should be designed so its effectiveness can be tested :

Control Element

Testability Consideration

What is the control?

Can it be clearly described?

Who owns it?

Is ownership assigned?

How is it executed?

Is the procedure documented?

How is it evidenced?

Is evidence generated by operation?

How is it tested?

Can effectiveness be measured?

Control Design Steps

Step 1: Identify the Requirement

What requirement must be met? Regulatory, contractual, or internal policy.

Step 2: Define the Control Objective

What outcome should the control achieve? Be specific and measurable.

Step 3: Select Control Type

Will it be preventive, detective, or corrective?

Step 4: Design the Control Activity

What specific action will be taken? Who will do it? When will it happen?

Step 5: Assign Ownership

Who is accountable for the control's operation? Who is responsible for executing it?

Step 6: Define Evidence

What proof will demonstrate the control is operating effectively?

Step 7: Design Testing

How will the control be tested? How often?

Real-World Example: End-User Spreadsheet Controls

Smythe & Smythe International evaluated spreadsheets in its financial close process and identified high-risk spreadsheets based on susceptibility to error and significance to financial statements . They implemented:

  • Input Control: Input data is reconciled to source documentation 
  • Access Control: File-level access is limited to approved users, password required 
  • Version Control: Standard naming conventions ensure only current versions are used 
  • Calculation Testing: Formula changes are tested against manual calculation 
  • Overall Analytics: Analytical business process reviews detect errors 

Conclusion

Control design is the foundation of effective controls management. Organizations that design controls around outcomes, document technology dependencies, design for testability, and assign ownership will have controls that operate effectively in practice.


Action Items for Your Organization

  • Review existing controls for outcome-based design
  • Document technology dependencies for key controls
  • Ensure controls are designed for testability
  • Assign clear ownership for each control
  • Define evidence requirements for each control