TSC-CC5.2 Guidance

TSC-CC5.2 (COSO Principle 11) requires you to define, implement, and prove the operation of “general control activities over technology” that support your SOC 2 control objectives. Operationalize it by documenting your IT general controls (ITGCs), mapping them to in-scope systems, running them consistently, retaining audit-ready evidence, and periodically testing effectiveness ¹.

Key takeaways:

• You need a documented set of ITGCs that cover access, change, operations, and monitoring for in-scope technology ¹.
• Evidence matters as much as design: retain logs, tickets, approvals, and review sign-offs that show controls operated ¹.
• Build a repeatable cadence: monitoring, review, and periodic assessments are the difference between “policy” and “control” in a SOC 2 exam ¹.

TSC-CC5.2 guidance requirement is where many SOC 2 programs either become real or stay performative. The criterion ties directly to COSO Principle 11 and expects you to “select and develop general control activities over technology” that reduce risks created by systems you rely on to deliver services ¹. For a CCO or GRC lead, the work is not to write a long IT policy library. The work is to decide what technology is in scope, define a small set of control activities that actually manage the risks, and make those controls provable through consistent evidence.

Auditors typically test two things under this requirement: (1) did you design sensible technology controls for the environment you operate, and (2) did those controls run throughout the audit period with reliable artifacts. If either is weak, you get exceptions that can ripple into multiple Trust Services Criteria because technology is the foundation for security, availability, confidentiality, processing integrity, and privacy controls.

This page gives requirement-level implementation guidance you can execute quickly: scope decisions, control design patterns, step-by-step operating procedures, and the evidence pack you should be able to produce on request.

Regulatory text

Excerpt (TSC-CC5.2): “COSO Principle 11: The entity selects and develops general control activities over technology.” ¹

What the operator must do

Translate that sentence into a set of IT general controls (ITGCs) that are appropriate for your systems and risks, then run them consistently and retain evidence that proves they operated ¹. “General control activities over technology” generally means controls that govern:

• Access to systems and data (who can log in, what they can do, and how access is reviewed)
• Changes to systems (how code/config changes are requested, reviewed, approved, and deployed)
• Technology operations (backups, job monitoring, incident handling, vulnerability remediation, configuration baselines)
• Monitoring (logging, alerting, and management review of technology performance and security signals)

Your auditor does not need your controls to look like any specific framework. They do need a defensible set of controls mapped to in-scope systems, with evidence, and with periodic review/testing ¹.

Plain-English interpretation (what this requirement really means)

If technology failure or misuse could break your commitments to customers, you must have “guardrails” that prevent, detect, and correct those failures. Under the tsc-cc5.2 guidance requirement, a policy alone is not a guardrail. A control is a guardrail only when:

1. It is defined (clear owner, frequency, scope, and procedure).
2. It is performed (consistently during the SOC 2 audit window).
3. It is provable (tickets, logs, approvals, review sign-offs, and system reports).
4. It is checked (monitoring and periodic assessments confirm it works) ¹.

Who it applies to (entity + operational context)

Applies to: Organizations undergoing a SOC 2 examination using the AICPA Trust Services Criteria ¹.

Operationally applies to:

• Product and platform engineering teams that deploy code/configuration
• IT and security teams that administer identity, endpoints, networks, and cloud
• SRE/operations teams that run production systems
• GRC teams that define controls, collect evidence, and coordinate testing
• Any third party providing in-scope technology components (for example, cloud hosting, identity providers, ticketing/logging tools), because your control activities may depend on their controls

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

Step 1: Freeze SOC 2 scope for “technology”

Create (or confirm) an inventory of in-scope systems that support the services covered by the SOC 2 report. At minimum, include:

• Production applications and supporting services (APIs, databases, queues)
• Identity platform (SSO/IdP), endpoint management, and admin consoles
• CI/CD platform and source control
• Logging/monitoring and ticketing systems

Output: “System inventory (SOC 2 scope)” with system owner and where evidence will come from.

Step 2: Select a baseline ITGC control set

Build a minimal, auditable set of technology control activities. Most teams group them into four families:

1. Access controls

• Joiner/mover/leaver process for workforce members
• Privileged access management approach (or compensating controls)
• Periodic access reviews for key systems

2. Change management

• Change requests tracked in tickets/PRs
• Peer review requirement for code changes
• Approval gates for production deployments
• Separation of duties or compensating review where admins deploy

3. Technology operations

• Backup configuration and restore testing approach
• Incident management workflow and on-call
• Vulnerability scanning and remediation workflow
• Configuration management expectations for production

4. Monitoring and review

• Central logging for key systems
• Alerting thresholds and response expectations
• Management review of operational/security signals, with documented follow-up

Tip for operators: If you can’t describe “who does what, how often, and where the evidence lives” in one paragraph per control, the control is not ready for audit.

Step 3: Document the controls at “audit depth”

For each control, write a control statement that includes:

• Objective: what risk it addresses
• Scope: which systems/teams
• Owner: role or team
• Frequency: event-driven, daily, weekly, monthly, quarterly
• Procedure: steps a person follows or automated mechanism
• Evidence: specific artifacts produced
• Exceptions handling: what happens when the control fails

This maps directly to “Document formal policy or procedure” as a recommended control approach ¹.

Step 4: Implement monitoring and a review cadence

Auditors look for controls that run without heroic effort. Add:

• A calendar-based cadence for recurring controls (access reviews, log reviews, vulnerability remediation reviews).
• A lightweight management review memo or ticket comment template that captures: what was reviewed, what was found, and what was done.

This aligns to “Establish monitoring and review process” ¹.

Step 5: Build an evidence pipeline (don’t collect screenshots at the end)

Decide now how you will retain artifacts:

• Use your ticketing system for approvals, reviews, and exceptions.
• Use immutable logs where possible (SIEM or logging platform exports).
• Store evidence in a controlled repository with consistent naming.

Your goal is an “audit trail of activities” that is complete and repeatable ¹.

Step 6: Test control effectiveness and close gaps

Run a periodic assessment to confirm controls are working as designed and evidence is sufficient. Do this before your auditor does. Capture:

• Test steps performed
• Sample selections
• Exceptions found
• Remediation actions and retest results

This aligns to “Conduct periodic assessments” and “Test control effectiveness” expectations ¹.

Where Daydream fits (without changing your operating model)

If your evidence and control mapping is spread across Jira, GitHub, Okta, AWS, and spreadsheets, Daydream can act as the system of record for the tsc-cc5.2 guidance requirement: map controls to systems, assign owners, automate evidence pulls where possible, and track testing and exceptions in one place. The practical win is fewer last-minute evidence drills and fewer version-control problems on audit artifacts.

Required evidence and artifacts to retain

Use this as your “audit request readiness” checklist:

Control area	Evidence examples (retain)	What auditors are verifying
Access provisioning	Access request/approval tickets; IdP admin logs; onboarding/offboarding records	Only authorized users have access 1
Privileged access	List of privileged accounts; approval records; periodic privileged access review	Admin access is limited and reviewed 1
Access reviews	Review report export; reviewer sign-off; remediation tickets	Review happened, was meaningful, and had follow-up 1
Change management	Pull requests; peer review evidence; deployment logs; change tickets	Changes were authorized, reviewed, and traceable 1
Operations (backups)	Backup configs; job success logs; restore test record	Backups exist and are recoverable 1
Incident response	Incident tickets; post-incident reviews; customer comms approval records (if applicable)	Operational issues are managed and corrected 1
Vulnerability mgmt	Scan outputs; remediation tickets; patch/upgrade records; risk acceptance approvals	Known issues are tracked and addressed 1
Monitoring	Log retention settings; alert rules; review notes; escalations	Signals are monitored and acted upon 1
Control testing	Internal test plans; samples; results; remediation and retest	Controls work over time, not on paper 1

Common exam/audit questions and hangups

Expect these questions, and prepare concise answers with pointers to artifacts:

1. “What systems are in scope for SOC 2, and why?”
   Hangup: teams can’t produce a stable inventory or boundaries.

2. “Show one change from request through deployment.”
   Hangup: emergency changes, console edits, or missing approvals.

3. “How do you review access to production and cloud consoles?”
   Hangup: reviews are informal, not retained, or miss service accounts.

4. “Where is evidence stored, and how do you prevent tampering?”
   Hangup: evidence is scattered; screenshots lack context.

5. “How do you know controls worked throughout the period?”
   Hangup: one-time setup evidence instead of period-long operation.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Writing policies that don’t match reality.
  Fix: document the actual workflow in Jira/Git/CI, then tighten it iteratively.

• Mistake: Treating cloud-provider controls as a substitute for your controls.
  Fix: document what you rely on the provider for, then implement your side (identity, configuration, logging, change control).

• Mistake: “Access review” as a spreadsheet with no outcome.
  Fix: require remediation tickets for removals/changes and attach them to the review record.

• Mistake: No evidence for automated controls.
  Fix: retain system configuration exports, logs, and screenshots with timestamps and system identifiers.

• Mistake: No periodic assessments.
  Fix: schedule internal control tests and track exceptions like incidents, with owners and closure dates.

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime ¹. The risk is still real: weak technology control activities commonly lead to audit exceptions, delayed reports, or qualified opinions, and those outcomes can trigger customer contract issues or security assurance failures. Treat TSC-CC5.2 as “table stakes” assurance hygiene for any service organization that operates production systems.

A practical 30/60/90-day execution plan

Days 1–30: Scope + control design (get to “auditable on paper”)

• Confirm in-scope systems and owners.
• Select your ITGC baseline (access, change, operations, monitoring).
• Draft control statements with owner/frequency/evidence fields.
• Decide evidence storage location and naming conventions.

Days 31–60: Operate controls + start evidence capture (get to “auditable in practice”)

• Run at least one full cycle of each recurring control (access review, log review, vulnerability review).
• Clean up workflows that break traceability (console changes, missing approvals).
• Create exception handling workflow (risk acceptance, emergency change process).

Days 61–90: Test + remediate (get to “auditable under scrutiny”)

• Perform an internal control effectiveness test with sampling across the period-to-date.
• Remediate findings and retest.
• Conduct a management review of the ITGC program and record decisions (scope changes, control changes, tool changes).

Frequently Asked Questions

Does TSC-CC5.2 require specific IT controls like access reviews and change approvals?

TSC-CC5.2 requires that you select and develop general control activities over technology, but it does not prescribe a single mandatory control list ¹. In practice, access, change, operations, and monitoring controls are the common patterns auditors expect to see supported by evidence.

How detailed do control descriptions need to be for SOC 2?

Detailed enough that a new operator could execute the control and produce the same evidence. If your control statement lacks owner, frequency, scope, and evidence location, it will usually fail audit scrutiny ¹.

What counts as “evidence of operation” for automated controls?

Configuration exports, immutable logs, system-generated reports, and alerts with timestamps typically work well. Pair the artifact with a short note that explains what the control is and what the evidence demonstrates ¹.

We use third-party cloud services. Can we inherit controls from them?

You can rely on third-party controls for parts of the stack, but you still must define and operate your control activities over the technology you manage, especially identity, access, configuration, and monitoring. Document the boundary and keep the third party assurance reports as supporting context.

How do we handle emergency changes without failing change management?

Define an emergency change path that still creates traceability: record the change, capture who approved it, and require after-the-fact review within your normal workflow. Auditors usually accept emergency paths when they are rare, defined, and reviewed with evidence.

What is the fastest way to reduce SOC 2 exceptions tied to TSC-CC5.2?

Standardize evidence capture in the systems where work happens (tickets, PRs, CI logs) and schedule recurring reviews on a calendar. Tools like Daydream help by centralizing control ownership, mapping controls to systems, and keeping an audit-ready evidence trail.

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