CC1.4 Commitment to competence: SOC 2 requirements

What CC1.4 commitment to competence asks for in a SOC 2

When an auditor asks how you make sure your people are qualified for their roles, they are testing CC1.4. The criterion restates COSO Principle 4: the organization is committed to attracting, developing and retaining competent people in line with its objectives. In practice, the auditor expects to see a deliberate system behind staffing, not just a list of résumés. That system covers how roles are defined, how candidates are screened, how competence is checked after hiring, how technical skills are kept current, and how the company plans for the loss of a key person. The risk behind the criterion is simple: a control is only as good as the person operating it. An access review performed by someone who does not understand the systems, or a change approval given without knowing what the change does, can pass on paper and still fail in practice.

CC1.4 is hard to evidence over a Type 2 observation period because competence is not a single event. A hiring file shows that a candidate was screened on the day they joined. It does not show that they were still competent in month nine, after the platform changed and a new cloud service was added. Auditors therefore look for recurring records: role descriptions kept current, competence evaluations, training completed and tied to job duties, and evidence that gaps were addressed. Ask your auditor early which samples they will pull and over what period, so you can confirm that the records exist for the whole window rather than assembling them at the end. The AICPA 2017 Trust Services Criteria list the points of focus that guide this work.

CC1.4 is often confused with CC1.5, but the two answer different questions. CC1.4 asks whether the organization builds and keeps a competent workforce: how it hires, trains, evaluates and plans succession. CC1.5 asks whether individuals are held accountable for their internal control responsibilities through performance measures, consequences and attention to pressures that could push people to cut corners. A company can have excellent hiring and training and still have weak accountability, or the reverse. Plan evidence for both separately, so that the records for CC1.4 show capability and the records for CC1.5 show follow-through.

Which roles, teams and third parties fall under CC1.4

CC1.4 applies to the people who build, operate and secure the system described in the report, not to the whole company by default. The scoping decisions below determine which roles an assessor will expect to see evidence for, and which ones the organization must document as out of scope or covered by someone else's report.

Teams that operate in-scope systems

Start from the system description and list every team that builds, deploys, operates, supports or secures the in-scope services. This usually includes engineering, platform or DevOps, security, support staff with production access, and the managers who approve hiring for those teams. For each team, document the role profiles, the skills the role requires and the training that keeps those skills current. Teams that only touch corporate systems may be outside the boundary, but the decision should be written down and reviewed when the system changes.

Privileged and production access roles

Roles with privileged access need stronger competence evidence than other roles. Database administrators, cloud account owners, incident responders and people who can change production configuration should have documented qualifications, role-specific technical assessments and a recorded review before access is granted. Ask whether these roles are filled through the same hiring steps as the rest of engineering, and whether anyone can obtain production access without a competence check.

Contractors and temporary staff

Contractors who work on in-scope systems are part of the population the criterion covers, even though they are not employees. Confirm how their competence is established, whether through the agency's screening and training records, the contract's qualification requirements or the organization's own assessment. Ask who supervises their work and where their training evidence is kept, since an assessor will expect to see it in the same form as employee records.

Managed service and subservice providers

When a managed service provider runs part of the in-scope system, the question is whether that provider's SOC 2 report covers its own staff competence and whether the organization relies on it. Decide whether the provider is a subservice organization carved out of the report, or included through inclusive treatment. Either way, the organization should keep records of the provider's competence commitments and review the provider's report and exceptions for CC1.4-related findings.

Leadership and oversight roles

Executives and board members are not usually tested for technical competence under CC1.4, but the organization must show that the people who set security priorities understand them. Document the security responsibilities of the chief technology and security officers, and show how they receive training on the risks in the system. Confirm with your auditor whether leadership roles fall inside the criterion for your scope, because the answer changes which records you need to produce.

How an assessor tests CC1.4

This table walks through how a service auditor typically tests each CC1.4 point of focus, what evidence they request, how they sample hires, leavers and training records over the examination period, and the findings that appear most often. Use it to prepare records before fieldwork rather than after the auditor asks for them.

Point of focus	Evidence the assessor requests	Sampling and common findings
Competence policies and practices	Written hiring and role-competence policy, role descriptions for in-scope positions, approval records showing the policy was followed	Auditor selects a sample of hires in the period and checks each against the stated requirements. Common finding: role descriptions missing or out of date for engineering and operations roles
Evaluating competence and addressing shortcomings	Documented competence evaluations (interview scorecards, probation reviews, annual reviews), and records of follow-up actions such as coaching or development plans	Auditor samples employees and checks that evaluations occurred on schedule and that gaps led to action. Common finding: evaluations performed but no recorded response to identified shortcomings
Succession planning	Documented succession or continuity plan for key security, infrastructure and operations roles, with named backups and cross-training records	Auditor asks which roles are key, then tests whether a backup is named and trained. Common finding: a single person holds all administrative access with no documented successor
Background checks and technical training	Background check policy and completion records for hires, training plans, completion logs for technical and security courses, and records showing training was linked to competence	Auditor samples new hires for background check evidence and samples training records across the period. Common finding: training completion recorded, but no evaluation of whether skills improved

How to build a competence program that passes testing

This sequence turns CC1.4's commitment to competent people into role requirements, hiring and screening rules, training plans, evaluation records and succession coverage that an assessor can sample and trace.

Define competency requirements for each role
Management, with HR and the system owners, lists the roles that touch in-scope systems and writes the knowledge, skills and certifications each role needs to meet the organization's objectives. The output is a role competency matrix that names the critical roles, the technical skills behind security and operations work, and the owner of each role definition. The step is done when every in-scope role has a written entry and the matrix has been approved by a named manager.
Set hiring and background check standards
HR writes the screening standard that applies before someone gets access to in-scope systems: how candidates are assessed against the role matrix, which checks apply by role, how checks are performed and by whom, and what happens when results are adverse. Contractors and vendor staff with system access should be covered by the same standard or an equivalent contractual one. The output is a hiring and screening procedure plus a record for each hire showing the checks completed and the approval. Confirm with counsel which checks your jurisdiction permits.
Establish technical training plans
For each role in the matrix, the manager and the security lead agree a training plan that maintains technical competence: onboarding for new hires, secure development and operations courses, vendor or tool certifications where they matter, and refresher content when systems change. Plans should name the courses, the audience and the completion record. Learning platforms such as Moodle can record completion, though activity completion depends on how each activity is configured, so confirm that the settings reflect what you claim. The output is a training plan per role and a completion log.
Run competence evaluations
Managers evaluate whether people in critical roles actually hold the competencies in the matrix, using a method that fits the role: structured interviews, practical exercises, supervised tasks, or review of work products. The evaluation is recorded against the role requirement, with the date, the evaluator and the result. The output is a completed evaluation record for each person in a critical role, which an assessor can sample against the matrix.
Document shortcomings and remediation
When an evaluation or a training record shows a gap, the manager logs the shortcoming, agrees a remediation step such as additional training, supervised work or reassignment, and records when the gap is closed or escalated. Repeated gaps in one role may signal that the matrix or the hiring standard needs changing, so the security lead reviews patterns. The output is a shortcomings log linked to the evaluation and training records, showing each gap from identification to closure.
Set succession coverage for critical roles
Management identifies the roles whose loss would disrupt in-scope systems or controls, names at least one person who could cover each one, and records the transition steps and access that cover would need. The plan should be tested at least once, for example by having the covering person run a documented task under supervision. The output is a succession plan for critical roles, with named cover, the knowledge and access handover steps, and a record of the test, which supports the availability and business continuity work in other criteria.

Which records prove commitment to competence

An auditor testing CC1.4 looks for records that show competence was defined, checked, developed and replaced deliberately. The cards below cover the artifacts that usually carry that proof, how to keep each one current between audits, and how to tie each record to the systems inside your SOC 2 boundary.

Role competency descriptions

A role competency description states the skills, experience and technical knowledge expected for each job that touches in-scope systems, such as platform engineers, support staff and database administrators. It is the yardstick every later check is measured against, so it has to exist before the first hire is evaluated. Review each description when a role changes or a system in the boundary is replaced, and record the review date and approver. Confirm with your auditor how far down the org chart they expect descriptions to reach.

Hiring checklists

A hiring checklist records the steps taken before an offer: interview scorecards, skills assessments for technical roles, reference checks and the approval given. It shows that competence was considered at the point of hire rather than assumed. Keep one completed checklist per hire in the same system as the personnel file, and make sure the checklist names the role it was used for. Ask the auditor which hires they will sample so you know which files need to be complete.

Background check results

Background check results show that screening was carried out for candidates in the roles your policy designates, including the scope and the date the check was completed. Store the outcome and the decision made on it, not the underlying personal data beyond what your retention policy allows. Check that the screening provider and the jurisdiction rules were followed for each candidate. Confirm with counsel which checks are permitted in each country where you hire.

Training completion logs

Training completion logs show who finished which technical or security training, when, and whether the course passed a knowledge check. An LMS such as Moodle can record completion automatically when a learner views an activity, receives a grade, or ticks it off, depending on how each activity is configured. Set the completion conditions deliberately, because a view-only rule proves attendance, not competence. Export the logs at regular intervals so they survive the period under audit.

Performance and competence review notes

Review notes record how each person's skills were assessed against their role description, what gaps were found and what was agreed. They are most useful when they name a specific skill, such as incident triage on a production system, rather than a general rating. Write the notes at a fixed cadence and keep the manager's and employee's sign-off. Confirm with your auditor how these notes relate to the performance measures tested under CC1.5.

Remediation plans and succession plans

A remediation plan sets out how a documented skills gap will be closed, with an owner, a training path and a completion date. A succession plan names a backup for each critical role, such as the only engineer who can rotate keys or restore backups, and the knowledge transfer steps behind that name. Both documents should be dated and reviewed when people leave or systems change. Tie each critical role to the systems in the boundary so the auditor can see the coverage gap was addressed.

What meeting CC1.4 costs in money and effort

This table lists the cost and effort components of meeting CC1.4, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No figures are given because none were supplied for this topic, so use the questions in the right-hand column when requesting quotes or budgeting internally.

Cost component	Who is paid or who spends time	One-time or recurring, and main driver
Background check vendor fees	The screening provider, billed per candidate or per check package; the organization pays directly or through its recruiting budget	Recurring with hiring volume. Drivers: number of hires, depth of checks by role, and jurisdiction rules. Ask for per-check pricing and any minimum fees.
Training content or licenses	Commercial course providers or internal authors; learning platform licenses if a hosted LMS is used	Mostly recurring (annual licenses or renewals). Drivers: seat count and content breadth. A self-hosted open-source learning platform such as Moodle, licensed under GPL-3.0-or-later, can remove per-seat license spend, though hosting and course authoring remain.
Competency criteria and evaluations	Hiring managers and subject-matter leads writing role criteria, then running assessments	One-time to write role criteria, recurring to run evaluations. Drivers: number of roles and how often they change. Managers' time is usually the largest internal cost.
Technical training time	Engineers' time away from delivery, plus any trainer or mentor time	Recurring. Drivers: how many technical competencies must be maintained and whether training is tracked to completion for the auditor.
Succession planning	Leadership and HR time to identify and document backups for critical roles	Initially one-time, then reviewed periodically. Drivers: size of the team and number of single points of knowledge.
Evidence tracking and completion records	Compliance or operations staff who gather records for the auditor	Recurring. Drivers: whether completion records are captured automatically in the learning platform or collected by hand.
Auditor sampling effort	The CPA firm, billed under the engagement letter; staff time from the organization to answer requests	Recurring each examination period. Drivers: sample sizes the auditor selects, the number of hires and roles in scope, and how easily samples can be pulled.
Implementation partner support (if used)	The partner, under a written fixed scope	One-time setup, optional retainer for upkeep. Ask what is included in the written scope and what happens after handover.

How a learning platform turns training into audit evidence

A training record only persuades an assessor when it shows that a specific person in a specific role completed the technical training their job requires. A list of courses with a 'completed' status for everyone is weak evidence, because it does not show that the training matched the role. For CC1.4, the useful question is whether the platform can show, for each engineer, administrator or security responsible person, which required modules they finished, when, and whether the content was tied to the competencies the organization decided that role needs. Open-source learning platforms such as Moodle can produce that record through activity completion. According to the Moodle developer documentation, an activity is marked complete for a learner when they view it, when they receive a grade from it, or when they tick it manually, depending on the conditions set for that activity. Each option produces a different kind of evidence. A view condition shows that the content was opened, which is weak for technical competence. A grade condition, tied to an assessment such as a lab exercise or a practical quiz, shows that the learner demonstrated something. A manual tick is the weakest of the three because it relies on the learner's word or a supervisor's action with no test behind it.

The completion condition should therefore match the training requirement written in the organization's own policy. If the policy says a platform administrator must demonstrate hardening steps, the activity should require a graded practical assessment, not a page view. Reviewers should check the activity completion settings for each required course, export the completion report, and confirm that a sample of learners' records matches the role matrix. Organizations should also confirm which completion conditions their own courses use, since the settings are chosen per activity by course designers and can differ between courses. Where a manual tick is unavoidable, pair it with a supervisor sign-off and keep the date, the approver and the course version. Retained records should also show what happened when a learner failed, so the evidence covers the 'addressing shortcomings' element of CC1.4 as well as completion.

Who owns competence, who can help, and what the auditor tests

The organization owns CC1.4 in full. Competence is a management responsibility, so the HR lead and engineering managers decide which roles matter, who fills them, how people are evaluated, and what training is required. The control is only credible if those owners act on it and can show that they did. A SOC 2 assessor will ask managers to explain their own decisions, so the program cannot be delegated to a vendor in practice even when outside help is used to draft it.

Role requirements: Managers define the skills each role needs and approve them, and they revisit them when responsibilities change.
Hiring and screening: HR runs the hiring process, reference checks and any background checks the company has chosen to perform.
Evaluation and remediation: Managers assess competence, record shortcomings and assign a plan to address them.
Succession planning: Leaders name backups for critical technical roles and record how knowledge is handed over.
Ongoing training: Managers schedule and approve technical training, then keep completion records.

Before the audit, confirm that each named owner can describe the program in their own words and point to records that show it was run.

Where competence controls usually fail

CC1.4 is tested through evidence that people are hired, trained, evaluated and replaced in a documented way. The failures below recur across service organizations, and each one leaves a gap an assessor can find by sampling roles, training records and evaluations.

No written role requirements

Job descriptions often exist for hiring but say little about the skills, certifications or experience a role needs to perform its controls. Without that baseline, the organization cannot show it evaluated candidates against any standard. Closure: maintain a current competence profile for each security-relevant role, such as administrators of production access, on-call engineers and change approvers, and tie it to the hiring checklist. Sample a few recent hires and confirm each profile was used.

Training unlinked to duties

Annual security awareness completion can be recorded for everyone while engineers who run key rotations or database restores never receive technical training for those tasks. An assessor may ask how training was chosen for a given role, and a generic course list will not answer that question. Closure: map each role's responsibilities to specific technical training, then keep completion records for that mapping. Where a training platform is self-hosted, the course completion setting can help record that a learner finished required content, but confirm what the platform counts as complete in your configuration.

Evaluations that lead nowhere

Performance reviews may note that a skills gap exists without any follow-up. CC1.4 expects the organization to evaluate competence and address shortcomings, so a recorded gap with no plan, deadline or outcome is a finding in waiting. Closure: require each evaluation that identifies a gap to produce a dated development action, and track its closure in the next review cycle. Keep the evaluation form, the action and the follow-up together so the sequence is visible.

Undocumented succession for critical roles

When one engineer holds the only knowledge of a backup restore, a firewall rule set or a cloud account recovery path, the organization has a single point of failure in its competence. Succession planning is one of the points of focus under CC1.4, and a departure can break controls that were operating the day before. Closure: identify the roles where only one person can perform a critical control, document the procedure, and assign and train a named backup. Confirm the backup has performed the task under supervision at least once.

Background checks applied inconsistently

Background screening may be run for some hires and skipped for contractors, transfers or people who join through an acquisition. Because the organization's own policy sets the screening scope, gaps between policy and practice are easy for an assessor to find. Closure: define which roles require screening, apply the rule to employees, contractors and transferees alike, and keep a record of each screening decision. Ask your counsel which checks are lawful in each jurisdiction where you hire.

CC1.4 questions buyers ask before hiring help

How much effort does CC1.4 take to satisfy in a SOC 2?

The effort depends on how much of the hiring, training and evaluation process already exists and is written down. CC1.4 asks the organization to show it is committed to attracting, developing and retaining competent people, so the auditor will look for a documented hiring standard, role descriptions, a record of competence evaluations, training history and some form of succession planning. A company with a standard hiring process and a training budget mostly needs to write it down and keep records. A company that hires informally will need to design the process, apply it to current staff and build a record of it. Ask any provider to split the work into policy drafting, process design, evidence collection and fieldwork support, and to tell you which parts recur each year.

Can a small company handle CC1.4 without outside help?

Often yes, provided one person owns the program and the records are kept as the work happens. The core artifacts are a competence policy, job descriptions that state required skills, a background check procedure applied consistently, a method for evaluating competence and addressing gaps, and a training log for technical skills. A small team can run these with a simple template set and a shared folder. Outside help is most useful when the company has no baseline to measure against, when the evidence is scattered across chat threads and spreadsheets, or when leadership wants an independent view before the examination starts. Whatever the choice, the organization owns the control; a partner can prepare the program and evidence but cannot make the hiring decisions.

What does CC1.4 require from managers day to day?

Managers carry most of the evidence burden for CC1.4. They need to assess the technical competence of candidates against written role requirements, record the outcome of performance and competence reviews, identify skill gaps for their teams, and approve training or development plans. They also participate in succession planning for critical roles, such as the people who operate production systems, manage access or respond to incidents. In practice this means a short, repeatable set of steps: a documented interview scorecard, a periodic review note for each person in a security-relevant role, and a training plan that is revisited. Ask providers how they will reduce this load, for example through templates and calendar reminders, and confirm that managers will sign off on the records.

How long must CC1.4 evidence cover in a SOC 2 Type 2 report?

A Type 2 report covers an observation period over which the auditor tests whether controls operated effectively, so CC1.4 evidence must exist across that whole period, not only on the examination date. The auditor will sample hires, reviews and training records from within the window and check that each one followed the documented process. The length of the observation period is set by the engagement and the organization's report type, so confirm it with your CPA firm in the engagement letter. A Type 1 report, by contrast, looks at the design of controls as of a single date. Organizations moving from Type 1 to Type 2 should start collecting competence evidence well before the observation period begins, because records created retroactively are weaker and are more likely to draw exceptions.

Can the auditor write our CC1.4 program for us?

No. The auditor is independent of the organization and must not design the controls it will test, because doing so would impair its independence. The auditor can explain what the criteria require, describe the evidence it will request and test the controls once they exist. The organization owns the policy, the hiring standard and the training program. An implementation partner can help prepare the documents, set up the record-keeping and assemble evidence for fieldwork, but the partner does not issue the report or attest to the control. Confirm with your CPA firm which preparation services it can provide without compromising independence before you engage anyone to help with CC1.4.

How does CC1.4 differ from CC1.5?

CC1.4 is about building capability: attracting, developing and retaining people with the competence the organization needs, and confirming that they keep their technical skills current. CC1.5 is about accountability: holding individuals responsible for their internal control duties through performance measures, incentives and, where needed, discipline. A practical way to separate them is to ask whether the evidence shows the organization put the right people in place and trained them (CC1.4), or shows it measured and acted on how those people performed their control responsibilities (CC1.5). The two criteria share some records, such as performance reviews, so it helps to label each record with the criterion it supports. Both sit within the CC1 control environment series.

What should we ask a provider about CC1.4 before signing?

Ask for a written scope that names the artifacts to be delivered, such as the competence policy, role descriptions, training records structure and evaluation template, and states who on your side must approve them. Ask how the work will be split between your staff, the provider and your CPA firm, and what is one-time versus recurring, such as annual competence reviews and ongoing training logs. Ask what drives the quote: the number of roles in scope, the maturity of current hiring and training processes, the number of systems that need competence records, and whether the observation period has already started. Confirm the deliverables in writing before work begins, and make sure the provider will not present itself as the source of the attestation.

How DeployOpen prepares competence evidence

DeployOpen's part in CC1.4 is to help the organization produce the records an auditor will sample, not to decide who is competent. Before any work starts, DeployOpen and the client agree the scope, deliverables and timelines in writing. For this criterion, that scope usually covers the technical training workflows on the self-hosted platforms DeployOpen deploys, such as course enrollment, completion tracking and the mapping of each course to the roles that must complete it. Where the client runs Moodle, for example, the team can configure activity completion so that each learner's record reflects whether they viewed the material, received a grade or were marked complete by a reviewer. Illustratively, a configuration like this gives a manager one place to show that an engineer finished the secure configuration course before taking production access.

The organization keeps ownership of its people decisions. It sets the hiring standards, decides how competence is judged, chooses which roles need which technical training, and handles succession planning and any shortfalls. DeployOpen does not evaluate staff, recommend hires or sign off on whether a person is competent. Before the engagement, confirm with your own HR and engineering leads which competence evaluations and training requirements already exist, because the platform can only record what the organization has decided to require. Ask the auditor which evidence formats they accept for training and completion records, since that determines how the platform should export them.

The output of the engagement is the system and the evidence, not the report. DeployOpen can help set up the training workflows, document how they run and prepare the records for the examination. An independent CPA firm performs the SOC 2 examination and issues any report, and DeployOpen does not issue audit reports, attestations or certifications. Ask any implementation partner to state in the written scope which records it will configure, who will hold their administrator access and how the client will retain ownership of the data and the completion logs.

CC1.4 Commitment to competence