TSC-CC5.3 Guidance

TSC-CC5.3 requires you to deploy control activities through documented policies and procedures, then prove those controls operate as written. To operationalize it fast, create a control-to-policy map, write or update the procedures that make controls executable, assign owners, set review cadence, and retain an audit trail that shows consistent performance over the SOC 2 period. ¹

Key takeaways:

• Documented controls are not enough; auditors expect procedures that drive repeatable execution and evidence of operation. ¹
• Build a control activities inventory and map each activity to an owned, current policy/procedure and a concrete evidence output. ¹
• Add monitoring, periodic review, and testing so the control set stays effective as systems and teams change. ¹

TSC-CC5.3 is one of the fastest ways to fail a SOC 2 audit without realizing it. Teams often have “controls” in a spreadsheet, but the day-to-day work happens through informal Slack messages, tribal knowledge, and one-off heroics. Auditors then ask a simple question: “Show me the policy or procedure that requires this control activity, and show me evidence it happened consistently.” If you can’t point to an approved procedure, an assigned owner, and a repeatable workflow that generates an audit trail, CC5.3 becomes a finding magnet.

This page translates the tsc-cc5.3 guidance requirement into an operator’s checklist. You’ll leave with a practical build plan: how to define the control activities that matter, how to express them in policies and procedures without writing a 200-page binder, how to wire them into tickets and system logs, and what evidence to retain so your SOC 2 auditor can re-perform or inspect the control. The goal is boring, repeatable compliance: the same result, every time, even when people are out, systems change, or priorities shift. ¹

Regulatory text

Excerpt (TSC-CC5.3): “COSO Principle 12: The entity deploys control activities through policies and procedures.” ¹

What the operator must do:
You must (1) define the control activities you rely on to meet your SOC 2 criteria, (2) formalize them in policies and procedures that people can follow, and (3) operate them in a way that produces evidence an auditor can inspect. CC5.3 is less about “having a policy” and more about proving the policy is translated into day-to-day execution via procedures, approvals, system configurations, and records. ¹

Plain-English interpretation (what CC5.3 really asks)

If a control matters, it needs a “home” in your governance system:

• Policy sets the rule and intent (what must be true).
• Procedure defines the steps (how you make it true, who does it, and what record is created).
• Evidence shows it happened (tickets, logs, access review exports, approvals, reports).

Auditors typically treat undocumented or inconsistently followed control activities as unreliable, even if your people “do the right thing.” CC5.3 pushes you to make security and compliance execution repeatable, inspectable, and resilient to change. ¹

Who it applies to (entity and operational context)

Entities: Any organization undergoing a SOC 2 audit that includes the AICPA Trust Services Criteria common criteria. ¹

Operational scope (where it shows up):

• Security and IT operations (access provisioning, change management, incident response)
• Engineering delivery (SDLC, code review, deployments)
• GRC operations (risk assessments, control testing, exceptions)
• HR/People Ops (onboarding/offboarding steps tied to access)
• Third-party risk management (intake, due diligence, approvals, monitoring)
• Finance/RevOps systems that affect logical access or sensitive data

If a process affects systems in scope for SOC 2, CC5.3 expects the control activities within that process to be deployed through policies and procedures, not just good intentions. ¹

What you actually need to do (step-by-step)

Step 1: Build a control activities inventory (start from reality)

Create a list of the control activities that operate today across in-scope systems. Keep it tight: focus on activities that reduce a defined risk (unauthorized access, insecure changes, missed incidents, unmanaged third parties).

Minimum fields to capture:

• Control activity name (verb + object, e.g., “Approve production access”)
• Risk addressed
• In-scope systems
• Owner (role + named backup)
• Frequency/trigger (event-driven, per release, periodic)
• Procedure link (the “how”)
• Evidence output (the “proof”)
• Exception path (how you approve deviations and record them)

Step 2: Map each control activity to a policy and a procedure

For each activity, confirm:

• A policy requires the behavior (e.g., Access Control Policy requires approvals and least privilege).
• A procedure tells operators exactly how to execute it (tooling steps, approvals, required fields, recordkeeping).

Practical rule: if a new hire asked “how do I do this?” and the answer is “ask Sam,” you don’t have a procedure yet.

Step 3: Standardize procedures so they are auditable

Use a consistent template:

• Purpose and scope (systems + teams)
• Roles and responsibilities (RACI is fine)
• Preconditions (inputs required)
• Steps (numbered, tool-specific where needed)
• Required approvals (who, where captured)
• Evidence generated (ticket type, report export, log location)
• Exceptions (who can approve, how documented)
• Review cadence and document owner

Step 4: Operationalize through workflow tooling (tickets, CI/CD, IAM)

Procedures should produce evidence as a byproduct:

• Access requests via IAM workflow or ticketing with approver captured
• Changes via change tickets, pull request approvals, and deployment logs
• Incidents via incident tooling with timestamps and post-incident review records
• Third-party intake via request forms, due diligence checklists, and approval logs

This is where many teams benefit from a GRC system. Daydream can act as the system of record for control descriptions, procedure links, evidence collection requirements, and periodic review tasks, so you are not chasing artifacts across shared drives and inboxes.

Step 5: Add monitoring and periodic review

CC5.3 expects controls to stay deployed as the org changes. Put a lightweight review loop in place:

• Procedure owner reviews for accuracy after major system/process change
• GRC validates evidence quality and completeness
• Fixes are tracked like any other change (ticket + approval + versioned doc)

Step 6: Test whether controls work (and record the results)

Testing closes the loop: you confirm the control activity is operating as designed and producing usable evidence. Your test approach can be simple:

• Define test steps (inspect, re-perform, sample)
• Record results and exceptions
• Track remediation and retest

Even for smaller programs, written test notes and captured artifacts prevent the “we do it, trust us” dead end. ¹

Required evidence and artifacts to retain

Keep artifacts that prove deployment (design) and operation (performance):

Governance and design

• Control activities inventory (control register)
• Policies relevant to in-scope criteria (approved, versioned)
• Procedures/SOPs (approved, versioned, with owner)
• RACI or responsibility assignments (can be embedded in procedure)

Operating evidence (examples)

• Access control: access requests, approvals, provisioning logs, access review outputs
• Change management: PR approvals, change tickets, deployment logs, emergency change records
• Incident response: incident tickets, timelines, post-incident reviews, corrective actions
• Third party risk: due diligence packets, security reviews, approvals, ongoing monitoring records
• Monitoring/review: periodic procedure review sign-offs, control monitoring reports
• Testing: control test plans, workpapers, findings, remediation tickets, retest evidence

Retention should cover the audit period and be easy to retrieve by control and date. CC5.3 issues often appear as “evidence exists, but you can’t find it fast” or “evidence doesn’t show the required approval.” ¹

Common exam/audit questions and hangups

Auditors tend to ask:

• “Show me the policy that mandates this control activity.” ¹
• “Show me the procedure operators follow, including approvals and evidence.” ¹
• “Who owns it, and how do you ensure it happens when they’re out?” ¹
• “How do you know the procedure is current after system changes?” ¹
• “Provide evidence for the audit period that the control operated consistently.” ¹

Hangups that cause delays or findings:

• Approvals exist but are not captured in a durable system of record.
• Procedures describe “what” but not “how,” so evidence varies by operator.
• Evidence cannot be tied to the control activity (no control ID, no date, no approver).

Frequent implementation mistakes and how to avoid them

1. Writing policies that read like aspirational statements
   Fix: Keep policies short, but force a “must” statement that the procedure can satisfy, and link the procedure explicitly.

2. Procedures that are too generic to execute
   Fix: Include tool steps, required fields, and where the evidence lives. If the evidence is a screenshot, define what must be visible.

3. No exception path
   Fix: Define how you approve emergencies (e.g., break-glass access, hotfix deploys) and how you document retrospective review.

4. No periodic review
   Fix: Assign document owners and make reviews a tracked task with evidence of completion.

5. Evidence sprawl
   Fix: Centralize references in a single control record. Daydream can store the control narrative plus pointers to the exact evidence locations, so evidence requests don’t become a scavenger hunt.

Risk implications (why operators care)

CC5.3 is a “plumbing” requirement: weak deployment through policies and procedures makes other controls hard to defend. If you cannot show consistent execution, auditors may reduce reliance on your controls and increase substantive testing, add findings, or require scope clarifications. Operationally, unclear procedures also increase the chance of inconsistent access decisions, unmanaged changes, and missed third-party risks. ¹

Practical 30/60/90-day execution plan

Days 1–30: Baseline and triage

• Define in-scope systems and processes for the SOC 2 period. ¹
• Build your control activities inventory and identify gaps (no policy, no procedure, no evidence).
• Pick the top workflows that must be stable: access, change management, incident response, and third-party intake.
• Standardize templates for policies/procedures and evidence expectations.

Days 31–60: Deploy and generate evidence

• Draft/update policies and procedures for the prioritized control activities; route for approval.
• Implement workflow capture (tickets, IAM approvals, PR templates) to create consistent evidence.
• Start collecting evidence in a structured way (by control, by month, by system).
• Run a first internal “audit dry run” to confirm you can retrieve artifacts quickly.

Days 61–90: Monitor, test, and harden

• Add monitoring checks and periodic review tasks for procedures and evidence quality.
• Perform control testing and document results, exceptions, and remediation.
• Tighten weak evidence (missing approvers, missing timestamps, unclear scope).
• Prepare an auditor-ready control narrative: what the control is, where the procedure is, and what evidence proves operation. ¹

Frequently Asked Questions

Do we need a separate policy and procedure for every control?

No. One policy can cover multiple control activities, but each control activity needs a clear procedure (or procedural section) that tells operators exactly what to do and what evidence is produced. ¹

What counts as “evidence of operation” for CC5.3?

Evidence is any durable record showing the control activity happened as required, such as tickets, system logs, approvals, exports, or signed reviews. The record must show date/time, scope, and who approved or performed the step. ¹

Our controls are automated in tooling. Do we still need procedures?

Yes. You still need documentation that explains what the automation does, who configures it, how changes are approved, and what logs/reports prove it ran. Automation reduces manual steps but does not remove the need for auditable deployment. ¹

How do we handle fast-moving engineering teams without creating process drag?

Put procedures where engineers already work: PR templates, CI/CD checks, and change records tied to deployments. Keep the narrative short, and let tooling produce the audit trail.

What if we discover a control activity has been happening but wasn’t documented?

Document it immediately, then start retaining evidence going forward. For earlier periods, preserve whatever records exist, but don’t backdate approvals or pretend a procedure existed when it did not.

How should third-party risk management map to CC5.3?

Treat third-party intake, due diligence, approval, and ongoing monitoring as control activities with procedures and evidence. Auditors often ask for proof that third-party reviews happen consistently, not only for the largest vendors. ¹

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017