A risk assessment gives management a basis for deciding what needs protection. SOC 2 CC5, Control Activities, addresses how those decisions become controls that people and systems can carry out. It connects the risks to the organization’s objectives with the activities intended to keep those risks within acceptable levels.
CC5 contains three criteria covering the selection of control activities, general controls over technology, and deployment through policies and procedures. Together, they help explain why particular controls exist and how the company puts them into operation.
A company can accumulate policies and security tools without establishing a coherent control approach. Teams may duplicate approvals in one workflow while overlooking another, or depend on an automated check whose configuration can be changed without oversight. CC5 encourages management to examine how the pieces support its objectives.
The connection to risk is important. If unauthorized production changes could expose customer information, management needs to consider how changes are requested, reviewed, implemented, and supported by the underlying technology. The selected activities should address the actual ways that risk could arise.
CC5 also provides a useful bridge to the more specific common criteria covering access, operations, and change management. Its focus is the reasoning and deployment behind the control approach. The detailed criteria provide additional expectations for particular areas of the system.
The labels below are editorial summaries, not official AICPA criterion titles.
See the AICPA Trust Services Criteria for the complete criteria and related points of focus.
A customer or business partner wants to understand whether the company has selected a sensible set of controls for the service being examined. Useful questions include:
Representative evidence might include risk-to-control mappings, process descriptions, documented responsibilities, approved policies, operating procedures, and records showing how activities are performed. Evidence about supporting technology could address administration, changes, and operations for systems on which the control depends.
For example, a company may require approval before a production deployment. Useful evidence explains who can approve, how the deployment mechanism enforces or records that approval, and how access to change the mechanism is controlled. This makes the relationship between business-process controls and technology controls easier to assess.
Evidence should reflect actual work. A procedure copied from another organization can create expectations the team cannot reliably meet. These examples do not prescribe a particular tool, policy format, or approval workflow.
A Type 1 report addresses the system description and suitability of control design as of a specified date. A Type 2 report also addresses operating effectiveness throughout a specified period. A reader should consider that difference when drawing conclusions about whether the described activities were performed consistently.
The report’s system description and scope determine which services and controls were examined. A cloud provider’s controls may support the service organization’s objectives, but the allocation of responsibilities still matters. Read the treatment of subservice organizations, relevant customer responsibilities, auditor’s opinion, and any applicable test results together.
In a five-person company with two founders and three employees, controls might rely on clearly assigned responsibilities, a second founder’s review of sensitive changes, and a small set of procedures maintained alongside the work. Where separating duties is impractical, management needs to consider alternative controls that address the resulting risk.
At roughly 100 employees, growing teams often need more consistent approval paths, defined ownership for shared systems, and procedures that work across departments. A change to an identity platform, for example, may affect several business processes and should have a clear owner.
At roughly 1,000 employees, common technology services and business-unit differences can make control dependencies more complicated. Shared standards, documented local variations, and coordinated ownership may help management understand how the overall approach fits together.
These examples are illustrative. Headcount alone does not determine control needs. Data sensitivity, system architecture, transaction volume, customer commitments, and the consequences of failure may justify substantial controls in a very small organization. The goal is a defensible approach suited to the service and its risks.
The individual articles will examine these topics in greater detail, with practical controls and supporting evidence. Links will be added as the articles are published.
Discuss your SOC 2 objectives with Genius GRC and identify controls and supporting evidence that fit your risk priorities, supporting technology, and day-to-day procedures.
