TSC-CC1.4 Guidance

To meet the tsc-cc1.4 guidance requirement, you must show that your organization consistently hires, develops, and retains people with the competence needed to run your SOC 2 scoped services and controls. Operationalize this by defining role-based competency requirements, executing structured hiring/onboarding/training, and retaining auditable evidence that these activities occurred and are periodically reviewed.

Key takeaways:

• Define “competent” per role and map it to your SOC 2 control owners and operational teams.
• Run hiring, onboarding, training, and performance practices that prove people can execute security and operational controls as designed.
• Keep tight evidence: job descriptions, training completion, access-to-training alignment, performance reviews, and periodic program review.

TSC-CC1.4 sits in the SOC 2 Common Criteria under COSO Principle 4 and focuses on people: whether the organization is committed to attracting, developing, and retaining individuals who can competently perform their responsibilities. Auditors do not accept “we hire good people” as a control. They look for a system: defined expectations, repeatable processes, and evidence that those processes operate throughout the audit period.

For a Compliance Officer, CCO, or GRC lead, this requirement usually becomes urgent right before fieldwork because it cuts across HR, Security, IT, Engineering, and Support. The fastest path is to treat CC1.4 like a control family: (1) document what competency means for each role that touches in-scope systems and controls, (2) implement lifecycle processes that build and maintain that competency (hiring, onboarding, training, evaluation, and retention), and (3) prove it with artifacts that stand up to sampling.

This page gives requirement-level implementation guidance you can execute quickly, with a bias toward what auditors request and where teams get stuck.

Regulatory text

Excerpt (TSC-CC1.4): “COSO Principle 4: The entity demonstrates a commitment to attract, develop, and retain competent individuals.” ¹

What the operator must do

You need a defensible, auditable talent-competency program for in-scope roles. In practice, that means:

• Attract: define required competencies and hire against them.
• Develop: onboard and train people so they can execute controls and operational duties correctly.
• Retain: evaluate performance, address skill gaps, and manage succession/coverage so critical responsibilities are consistently performed.

Auditors expect documented controls, evidence the controls operated, and some form of monitoring/review that confirms the program stays effective across the audit period. ¹

Plain-English interpretation

CC1.4 asks a simple question: Do you have the right people, with the right skills, doing the right work, consistently? If your incident response lead, IAM administrator, or customer support manager is not trained, not evaluated, or frequently backfilled ad hoc, your controls can exist on paper but fail in operation.

A good CC1.4 implementation links three layers:

1. Business and system scope: which products/services and systems are in the SOC 2 boundary.
2. Control execution: who performs access reviews, change approvals, vulnerability management, incident response, backups, etc.
3. Competency proof: what qualifies those people to do that work, how they were trained, and how you know they remain capable.

Who it applies to

Entity types: Any organization undergoing a SOC 2 audit that includes the Common Criteria. ¹

Operational context (typical):

• SaaS providers with in-scope production infrastructure and customer data handling
• Managed service providers running customer environments
• Organizations with material third parties where internal staff still own oversight and control operation

Roles most commonly in scope:

• Security leadership and practitioners (security operations, GRC, incident response)
• IT/IAM administrators
• Engineering leaders and deploy/CI owners
• Support/operations teams handling customer data or production access
• HR (as the process owner for onboarding and training records), even if HR is not “in scope” as a system

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

Step 1: Identify “in-scope roles” and control owners

• Export your SOC 2 control list and create a simple Control Owner Roster: control name, owner, backup, and team.
• Add operators who execute key steps (example: helpdesk staff who provision accounts; on-call engineers who execute incident steps).

Output: Control Owner Roster (owned by GRC; validated by Security/IT leadership).

Step 2: Define competency requirements per role (minimum viable)

Create a Role Competency Matrix with:

• Role title (or function)
• Responsibilities tied to controls (example: “performs quarterly access review”)
• Required knowledge/certifications/training (internal or external)
• Required system knowledge (tools, platforms)
• Minimum onboarding/training path
• Backup coverage requirement (who can step in)

Keep it practical. Auditors care that the matrix exists, is relevant to your controls, and is used in hiring/training decisions.

Step 3: Document lifecycle procedures (attract, develop, retain)

Write or update a short set of procedures. A single policy with linked SOPs is fine if it is clear and followed.

Minimum set:

• Hiring and role definition procedure: job descriptions, interview rubrics, background checks where applicable, and hiring approval.
• Onboarding procedure: security orientation, acceptable use, data handling, incident reporting, access provisioning guardrails.
• Training and development procedure: mandatory training, role-based training, and tracking mechanism.
• Performance and retention procedure: performance reviews, skill gap remediation, promotion/role changes, and offboarding triggers.

This aligns directly to “attract, develop, retain competent individuals.” ¹

Step 4: Implement training that maps to the control environment

Tie training to the reality of your control execution:

• Security awareness and data handling training for all personnel in scope
• Role-based training for privileged access administrators, deploy approvers, incident responders
• Tool-specific training where a tool is a control dependency (ticketing, IAM, SIEM)

Make the mapping explicit: Training Plan → Roles → Controls supported.

Step 5: Add monitoring and periodic review

Auditors often challenge programs that exist but do not get reviewed. Put a lightweight review into your calendar:

• Review competency matrix after major org changes (reorg, acquisitions, new product line)
• Review training completion and overdue items
• Review coverage for control owners and backups

Capture action items and completion evidence.

Step 6: Build an evidence pack that survives sampling

For SOC 2, your auditor will sample across the audit period. Prepare:

• A list of personnel in sampled roles during the period (including new hires and internal transfers)
• Training completion evidence for those people
• Evidence of performance reviews or documented check-ins
• Evidence of hiring standards (job descriptions, interview rubrics) for sampled hires

If you can’t produce evidence for a departing employee, the audit exception tends to land here.

Required evidence and artifacts to retain

Use this checklist as your “request-ready” folder structure:

Governance and design evidence

• CC1.4 policy/procedure(s) covering attract/develop/retain
• Role Competency Matrix (dated, versioned)
• Control Owner Roster with primary and backup assignees
• Training Policy and mandatory training catalog
• Training-to-controls mapping (simple table is enough)

Operating evidence (examples auditors actually sample)

• Job descriptions for in-scope roles
• Interview scorecards or hiring rubrics (even a lightweight template)
• Onboarding checklists (HR and Security/IT portions)
• Proof of training completion (LMS export, certificates, attendance logs)
• Performance review records or documented performance check-ins
• Evidence of corrective action for skill gaps (training assignment, coaching plan)
• Periodic review meeting notes, tickets, or approvals (who reviewed, what changed)

Audit trail characteristics

• Dated records
• Individual attribution (name or unique identifier)
• Immutable or controlled changes (version history, ticketing audit log)

Common exam/audit questions and hangups

Auditors tend to probe CC1.4 through “show me” questions:

• “Who are the control owners, and what qualifies them?” Have the roster and competency mapping ready.
• “How do you ensure new hires are competent before granting privileged access?” Expect scrutiny around onboarding, training prerequisites, and access provisioning sequencing.
• “How do you track training completion over the audit period?” Exports, not screenshots. Show overdue handling.
• “What happens when a key control owner leaves?” Show backup coverage and transition evidence.
• “How do you know training is effective?” Even basic checks help: manager attestations, quizzes, or completion plus role-specific sign-off.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in SOC 2	Fix
Competency is implied, not defined	Auditors can’t test “implied”	Publish a Role Competency Matrix tied to controls
Training exists but doesn’t map to roles	Looks generic and non-risk-based	Map training to in-scope roles and control responsibilities
No evidence for contractors or temps	Contractors often execute controls	Include third-party workforce in the roster and training tracking where applicable
Incomplete evidence for leavers	Sampling includes earlier periods	Keep archived evidence and maintain offboarding checklists
No periodic review	Programs drift	Add a scheduled review with documented outcomes

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime. Your risk is not a “fine,” it’s an audit outcome: control exceptions, qualified opinion risk, delayed report issuance, and customer trust friction during sales cycles. CC1.4 failures also correlate with real operational risk: misconfigured access, incomplete incident response, and inconsistent change management because the people running the process were not prepared or supported.

Practical 30/60/90-day execution plan

Day 0–30: Define scope and produce audit-ready design docs

• Build the Control Owner Roster (primary + backup).
• Draft the Role Competency Matrix for in-scope roles only.
• Publish or update the CC1.4 policy/procedures (keep it tight and testable).
• Inventory training sources (LMS, HRIS, spreadsheets) and decide the system of record.

Deliverables: Roster, matrix, policy/procedure set, evidence folder structure.

Day 31–60: Implement and backfill operating evidence

• Map required training to each in-scope role.
• Run a training completion campaign and track exceptions.
• Standardize onboarding checklists and require manager sign-off for role readiness.
• Start collecting performance evidence (mid-cycle check-ins are acceptable if annual reviews aren’t timed well).

Deliverables: Training plan + exports, onboarding artifacts, manager attestations.

Day 61–90: Prove monitoring and stabilize for the audit period

• Hold the first formal review: competency matrix review + training completion review.
• Document actions taken (new training added, roles updated, overdue remediated).
• Dry-run an “auditor sample” pack: pick a few hires, a few role changes, and a few control owners; assemble end-to-end evidence.

Deliverables: Review minutes/tickets, completed sample packs, remediation log.

Tooling note (where Daydream fits)

Most teams fail CC1.4 on evidence assembly, not intent. Daydream can help you maintain a single system for control ownership, role-to-control mapping, evidence requests, and audit-ready exports so HR, Security, and GRC aren’t chasing screenshots during fieldwork.

Frequently Asked Questions

What’s the minimum documentation to satisfy the tsc-cc1.4 guidance requirement?

A documented procedure for attracting, developing, and retaining competent staff plus a role-based competency definition tied to control responsibilities. You also need evidence the process operated during the audit period ¹.

Do contractors and consultants need to be included?

Include any third party workforce who performs in-scope control activities or has in-scope access. If they don’t complete your training, keep equivalent evidence (contractual training requirements, attestations, or certifications) and show onboarding/access gating.

Can we meet CC1.4 without an LMS?

Yes, but you still need reliable, reproducible evidence of completion and oversight. Spreadsheets can work short-term if they are access-controlled, versioned, and supported by certificates or attendance records.

What do auditors usually sample for CC1.4?

They commonly sample new hires, role changes, privileged roles, and control owners across the audit period. Prepare hiring evidence, onboarding checklists, training completion, and performance documentation for those samples.

How do we show “retention” without sharing sensitive HR details?

Provide process evidence (performance review cadence, skill gap remediation workflows, succession/backup assignments) and redact compensation or sensitive content. Auditors typically accept redactions if the remaining content proves the control operated.

What if training completion is late for a few employees?

Treat it like a control deviation: document the exception, complete the training, record manager acknowledgement, and adjust tracking or reminders to prevent recurrence. Auditors respond better to disciplined remediation than to missing records.

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 Trust Services Criteria 2017