TSC-CC1.3 Guidance

TSC-CC1.3 sits in the Common Criteria and is assessed in most SOC 2 examinations because it answers a basic audit question: is your control environment organized so responsibilities are clear, overseen, and enforceable ¹? For a CCO or GRC lead, the fastest path to readiness is to treat CC1.3 as an “accountability control” rather than a policy-writing exercise.

Operationally, CC1.3 fails when the org chart looks fine but nobody can show who owns risk decisions, who approves exceptions, how security escalations reach leadership, and how the board (or equivalent governing body) provides oversight. It also fails when governance exists only for the corporate entity while the SOC 2 in-scope system is run by a different team, region, or third party.

This page gives requirement-level implementation guidance you can execute quickly: how to define governance for the in-scope system, what artifacts auditors commonly request, how to avoid common documentation traps, and how to run a 30/60/90-day plan that results in testable evidence.

Regulatory text

Excerpt (TSC-CC1.3): “COSO Principle 3: Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities” ¹.

What the operator must do

You must be able to demonstrate, for the SOC 2 in-scope system and supporting functions:

1. A defined governance structure (management structure plus board or governing-body oversight).
2. Clear reporting lines that show where security, risk, compliance, IT, and engineering responsibilities sit.
3. Appropriate authorities and responsibilities (decision rights), including approvals, exception handling, and escalation paths.
4. Evidence the structure operates (not just diagrams): assigned roles, recurring oversight, documented decisions, and follow-through ¹.

Plain-English interpretation (what CC1.3 “means” in practice)

CC1.3 expects that accountability is designed into how you run the company and the in-scope system. An auditor should be able to pick any meaningful security or compliance decision (access exceptions, vulnerability risk acceptance, incident escalation, third-party onboarding, change approvals) and identify:

• the owner,
• who can approve,
• who must be consulted,
• who receives reporting,
• and where disputes or urgent issues escalate.

If the answer depends on tribal knowledge, you are exposed.

Who it applies to

Entity types: Any organization undergoing a SOC 2 audit where the Common Criteria are in scope ¹.

Operational contexts where this becomes “real”:

• High-growth orgs with frequent reorgs or rapidly changing ownership boundaries.
• Engineering-led companies where security/risk decisions happen inside delivery teams without formal escalation.
• Distributed operations (multiple regions, shared services).
• Material reliance on third parties (outsourced infrastructure operations, SOC, support, or development) where reporting lines and accountability get fuzzy.

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

Use this sequence to make CC1.3 testable quickly.

Step 1: Define the in-scope governance perimeter

• Confirm the SOC 2 system description boundary (product/service, environments, support teams).
• List the functions that materially affect the in-scope system: Engineering, SRE/IT, Security, GRC/Compliance, HR (onboarding/termination), Legal/Privacy (if relevant), Support/Operations, and third-party management.

Output: “In-scope governance perimeter” memo or section in your GRC repository that ties roles to the SOC 2 boundary.

Step 2: Establish your governance model (board oversight + management ownership)

• Identify the governing body that provides oversight (board, audit committee, security steering committee with executive sponsorship).
• Define what oversight means for you: risk updates, incident briefings, approval of major risk acceptances, and review of security program status.

Output: Governance charter(s) that state purpose, membership, scope, and responsibilities.

Step 3: Document reporting lines and RACI for key control areas

Build a compact set of diagrams and tables:

• Org chart extract covering the in-scope teams and security/compliance functions.
• Reporting and escalation diagram showing how issues move from operations to executives/board.
• RACI matrix for security and compliance decisions tied to your actual controls.

Minimum RACI rows to include (align to your environment):

• Access provisioning and deprovisioning oversight
• Change management approvals and emergency change authority
• Incident response leadership and executive notification
• Vulnerability management ownership, prioritization, and risk acceptance authority
• Third-party onboarding approval authority and contract/security review responsibility
• Policy exception approval and expiry responsibility

Output: One RACI table, one escalation flow, and one org chart excerpt that are consistent with each other.

Step 4: Define decision authorities and “stop/go” rights

Auditors commonly probe whether security and compliance have real authority. Write down:

• Who can approve access exceptions and for how long.
• Who can accept risk, at what level (team lead vs. VP vs. CEO/board).
• Who can halt a release for security reasons, and what the dispute path is.
• Who can sign off on third-party risk exceptions.

Output: Decision-rights matrix (often embedded into your security policy set or governance charter).

Step 5: Put monitoring and review on a calendar

CC1.3 is fragile during reorgs. Add a repeatable review:

• Review the org chart/RACI at a defined cadence and after triggering events (reorg, acquisition, major outsourcing, new product line).
• Track action items and close them.

Output: Calendar invites, meeting agendas, minutes, and action-item tracker entries that show follow-through.

Step 6: Build the audit trail package (evidence of operation)

Prepare a standing folder that contains:

• charters,
• current org chart excerpts,
• RACI and decision-rights matrix,
• meeting minutes and decks that show oversight,
• examples of escalations and approvals (sanitized if needed),
• change log showing updates after org changes.

Output: An evidence binder mapped to CC1.3 that you can hand to auditors.

Step 7: Test the control (don’t wait for the auditor)

Run an internal test:

• Sample a set of decisions (risk acceptances, incident escalations, third-party approvals).
• Verify the approvals match the defined authority.
• Confirm the board/oversight body received the expected reporting where required.

Output: Internal control test results with exceptions and remediation tickets ¹.

Required evidence and artifacts to retain

Keep artifacts that prove both design and operating effectiveness:

Governance design artifacts

• Board/audit committee/security steering committee charter(s)
• Security and compliance org structure (org chart excerpt)
• Reporting lines and escalation workflow
• RACI matrix for key controls
• Decision-rights / authority matrix (risk acceptance, exceptions, release stop authority)
• Role descriptions for control owners (job descriptions or internal role profiles)

Operating evidence artifacts

• Meeting agendas, minutes, attendance records, and decks showing oversight topics
• Examples of documented approvals (risk acceptance, exceptions, third-party onboarding approvals)
• Incident postmortems showing escalation to leadership when required
• Evidence of periodic review of governance artifacts (version history, change log)
• Internal testing records and remediation tracking ¹

Retention tip: Tie each artifact to a specific CC1.3 claim in your control narrative. Auditors penalize “document dumps” that don’t map cleanly.

Common exam/audit questions and hangups

Auditors typically get stuck on these:

1. “Who is the control owner?” If multiple teams “share” ownership, define a single accountable owner and supporting roles.
2. “Show me evidence the board provides oversight.” Provide minutes/decks where security risk, incidents, or program status are discussed, plus resulting actions.
3. “How do you ensure authority is enforced?” Show a real approval trail where an approver matches your authority matrix.
4. “What happens during a reorg?” Show a governance review trigger and an example update after an org change.
5. “Are third parties part of your operating model?” If outsourced, show how reporting and accountability flow from the third party to your management.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Org chart without decision rights.
   Fix: Add a decision-rights matrix and map it to real workflows (risk acceptance, exceptions, incident escalation).

2. Mistake: “Steering committee” in name only.
   Fix: Keep minutes and action tracking. Show that decisions are made and followed up.

3. Mistake: Governance exists at the company level, not the in-scope system.
   Fix: Annotate artifacts to show which functions/teams are in scope for the SOC 2 system.

4. Mistake: No evidence of periodic review.
   Fix: Version control your RACI/charters and schedule reviews. Capture approvals for updates.

5. Mistake: Inadequate testing procedures.
   Fix: Perform a simple sample-based internal test and log results and remediation ¹.

Enforcement context and risk implications

SOC 2 is an audit framework rather than a regulatory enforcement regime; CC1.3 risk shows up as qualified opinions, control exceptions, and customer trust friction, not fines ¹. Practically, weak CC1.3 correlates with:

• delayed incident escalation,
• inconsistent risk acceptance,
• access and change approvals that can’t be defended,
• and third-party oversight gaps where nobody owns the relationship end-to-end.

For third-party risk management (TPRM), CC1.3 becomes the “who owns the third party” question. If Procurement signs, Security reviews, and Engineering operates the service, your RACI must identify a single accountable business owner and define escalation routes.

Practical 30/60/90-day execution plan

Days 0–30: Document and align

• Confirm SOC 2 in-scope boundary and list impacted functions.
• Draft/update: governance charter, org chart excerpt, escalation flow, and RACI.
• Draft decision-rights matrix for risk acceptance and exceptions.
• Socialize with Security, Engineering, IT, Legal/Privacy (if relevant), and an executive sponsor for sign-off.

Deliverables: CC1.3 control narrative + draft artifact set ready for review.

Days 31–60: Operationalize and generate evidence

• Run at least one governance meeting cycle (steering committee or equivalent) and capture minutes/deck.
• Implement a lightweight approval capture method for risk acceptances and exceptions (ticketing workflow or GRC workflow).
• Train control owners on what evidence to save and where.
• Build the audit binder structure mapped to CC1.3.

Deliverables: Operating evidence (minutes, approvals, action items) plus evidence repository.

Days 61–90: Test and harden

• Perform an internal control test: sample approvals and escalations, verify against the authority matrix.
• Remediate exceptions: update RACI, adjust workflow permissions, or fix missing approvals.
• Set recurring review cadence and triggers (reorg, new third party, major product change).
• Prepare auditor-ready walkthrough: one narrative + mapped evidence.

Deliverables: Test results, remediation tickets closed or tracked, final evidence binder.

Where Daydream fits (practical, not theoretical)

If you’re coordinating multiple teams, Daydream helps you keep CC1.3 artifacts mapped to the in-scope boundary, track approvals as audit-ready evidence, and run periodic reviews with a clear audit trail. The value is fewer “where is that proof?” scrambles during fieldwork.

Frequently Asked Questions

Do we need an actual board, or is an executive committee enough for CC1.3?

CC1.3 requires “board oversight” in the COSO sense; in practice, your governing body can be a board, audit committee, or equivalent oversight forum if it has defined responsibilities and evidence of oversight ¹.

What’s the minimum documentation set an auditor will accept?

Expect to provide an org chart excerpt, governance charter, RACI/decision-rights documentation, and operating evidence such as minutes and approvals that match your defined authority ¹.

How do we show “appropriate authorities” without creating bureaucracy?

Limit decision rights to high-impact areas (risk acceptance, access exceptions, emergency changes, incident escalation). Use existing ticketing workflows to capture approvals so the evidence is created by normal operations.

We outsource key operations to a third party. Does CC1.3 still apply?

Yes. You still need internal accountability for oversight and decision-making, plus reporting lines and escalation paths between the third party and your management team.

What’s the fastest way to fail CC1.3 during a SOC 2?

Having governance documents that don’t match reality: wrong names, outdated reporting lines after a reorg, or approvals made by people who don’t have documented authority.

Can our RACI live inside policies, or does it need to be a standalone document?

Either works if it’s controlled (versioned), approved, and easy to map to control operation evidence. Auditors care that it’s current, consistent, and used.

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