SOC 2 CC5.3: Policies and Procedures

SOC 2 CC5.3 requires an organization to deploy its control activities through policies that state what is expected and procedures that put those policies into action, with named owners, timely execution, and periodic review. It closes the CC5 Control Activities series, and a frequent finding under it is a policy set that reads well on paper but describes commitments the organization does not actually keep.

What does SOC 2 CC5.3 require?

In plain terms, CC5.3 is where control activities become documented practice. Where CC5.1 selects the controls that mitigate risk and CC5.2 sets the general controls over technology, CC5.3 governs how those controls get written down and carried out day to day. A policy states what the organization commits to. A procedure states how someone performs the work that satisfies the commitment.

The criterion has two halves that have to line up. The policy establishes the expectation, and the procedure describes the steps, the owner, and the cadence that meet it. A policy with no matching procedure is an unenforceable statement of intent, and a procedure with no governing policy is an activity nobody committed to. CC5.3 also carries the maintenance obligation: someone accountable performs the work on time, corrective action follows when execution turns up a problem, and the policies and procedures get reassessed and refreshed so they stay current with how the organization operates.

CC5.3 maps to COSO Principle 12. It is the deployment principle: the point at which the control design work done in CC5.1 and CC5.2 turns into the documents and routines an auditor can test.

What are the CC5.3 points of focus?

The AICPA defines 6 points of focus for CC5.3. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Documents policies and procedures. The organization establishes policies and procedures that support deployment of management's directives, so each control activity has a written expectation and a written method for carrying it out.
• Assigns responsibility and accountability. Responsibility and accountability for executing policies and procedures sit with named roles, so each control activity has an owner rather than a default of nobody.
• Performs on time. Control activities are performed in a timely manner, following the timing the policies and procedures set, rather than only when an audit is near.
• Takes corrective action. When executing a control activity turns up a problem, the organization investigates and acts on it rather than logging the issue and moving on.
• Uses competent personnel. The people performing control activities have the competence and the authority the work requires, which ties CC5.3 back to the competence expectations in the CC1 series.
• Reassesses periodically. Policies and procedures are reviewed on a schedule and refreshed when the environment, the risks, or the way the work is done has changed.

How do you meet CC5.3 in cloud environments?

Cloud environments meet CC5.3 by keeping the policy library, the procedures, and the acknowledgement records in one governed system rather than scattered across wikis and drives:

• A policy set in a GRC platform. The full policy library lives in a GRC or governance platform with version history, an assigned owner per policy, and a review date, so each policy is a governed record rather than a static file.
• Procedures separated from policies. Step-by-step content that names hostnames, IP ranges, consoles, or dashboards lives in procedure documents linked to the governing policy, so an infrastructure change updates a procedure without triggering a full policy revision.
• Annual acknowledgement. Personnel acknowledge the policies on a defined cadence, and the platform records who acknowledged what and when, which is the evidence that the policy was deployed and not just written.
• Owners and cadence per control. Each control activity carries a named owner and a schedule, so the platform shows who is responsible and how often the work runs.
• Scheduled policy review. Policies carry a review date and a documented sign-off, so the reassess-periodically point of focus produces an artifact rather than a good intention.

How do you meet CC5.3 on-prem?

On-prem environments apply the same policy-and-procedure discipline where the work is performed against self-managed infrastructure rather than cloud consoles:

• A controlled policy library. Policies are held in a controlled document repository with version control, an owner, and an approval record, rather than in email attachments and shared folders where the current version is unclear.
• Runbooks as the procedure layer. Operational runbooks that carry server names, network addresses, and manual steps sit alongside the policy as procedures, so operators follow current instructions and policy commitments stay stable.
• Signed acknowledgement records. Staff acknowledge policies on a set cadence, with signed records retained, demonstrating the policy reached the people expected to follow it.
• Named owners and defined timing. Each control activity names the responsible role and states how often it runs, so execution is assigned rather than assumed.
• Documented periodic review. A scheduled review of the policy set is minuted and signed off, and outdated procedures are refreshed as part of that review.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC5.3?

How does CC5.3 map to ISO 27001:2022?

The overlap is full because both frameworks expect a governed set of policies and documented operating procedures with owners and periodic review, and the same policy library, acknowledgement records, and review evidence satisfy each. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC5.3 closes the CC5 Control Activities series that CC5.1 opens and CC5.2 continues: CC5.1 selects the controls, CC5.2 sets the general controls over technology, and CC5.3 deploys all of them through policies and procedures. The competent-personnel point of focus links back to the CC1 Control Environment series, since the people executing the policies need the competence and authority those criteria establish.

Frequently Asked Questions

What does SOC 2 CC5.3 mean?

SOC 2 CC5.3 requires an organization to deploy its control activities through policies that state what is expected and procedures that put those policies into action. It also requires named owners for each control activity, timely execution, corrective action when execution turns up a problem, competent personnel with sufficient authority, and periodic reassessment of the policies and procedures. It is the third criterion in the CC5 Control Activities series and maps to COSO Principle 12.

What evidence satisfies CC5.3?

The core evidence is a full policy library with version history and owners, procedures or runbooks linked to their governing policies, annual policy acknowledgement records, policy review and sign-off records showing periodic reassessment, and corrective-action records from control execution. Together these show that control activities are documented, assigned, performed on time, and kept current.

What is the difference between a policy and a procedure under CC5.3?

A policy states what the organization commits to, and a procedure states how someone performs the work that meets the commitment. A useful heuristic is that anything naming specific hostnames, IP addresses, or dashboard steps belongs in a procedure, not a policy. Keeping them separate means an infrastructure change updates a procedure without triggering a formal policy revision, so policies stay stable and current.

How often should policies be reviewed for CC5.3?

CC5.3 requires periodic reassessment without fixing a single interval, and most organizations review their policy set annually plus on any material change to the environment, the risks, or the way the work is done. The evidence auditors expect is a documented review with a sign-off, so the review produces an artifact rather than remaining an intention.

How is CC5.3 different from CC5.1?

CC5.1 selects and develops the control activities that mitigate risk, so it governs which controls the organization chooses and why. CC5.3 governs deployment: writing those controls into policies and procedures, assigning owners, performing them on time, and reviewing them. CC5.1 decides what controls exist, and CC5.3 makes sure they are documented and carried out.