Certified Lead SOC 2 Analyst key terms

The control criteria published by the AICPA covering security (common criteria) plus optional availability, processing integrity, confidentiality, and privacy categories, used as the benchmark against which a SOC 2 engagement is performed.

The set of security criteria (CC1 through CC9) that every SOC 2 report must include, addressing control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation.

The five groupings of criteria a service organization may include in scope: security, availability, processing integrity, confidentiality, and privacy; only security is mandatory, the others are added based on commitments and risk.

The optional trust services category (A1) addressing whether the system is available for operation and use as committed or agreed, covering capacity management, environmental protections, backup, recovery, and incident handling.

The optional trust services category (PI1) addressing whether system processing is complete, valid, accurate, timely, and authorized, with controls over inputs, processing rules, exception handling, and output review.

The optional trust services category (C1) addressing whether information designated as confidential is protected as committed or agreed, including identification, retention, and disposal of confidential data.

The optional trust services category (P series) addressing collection, use, retention, disclosure, and disposal of personal information consistent with the entity's privacy notice and applicable obligations.

The entity that operates the system providing services to user entities and is responsible for designing, implementing, and evidencing the controls described in a SOC 2 report.

The customer organization that uses the service organization's system and relies on the SOC 2 report, together with its auditors, to understand and assess controls affecting its own financial reporting or operations.

The service organization's narrative in a SOC 2 report describing the system's infrastructure, software, people, procedures, and data, plus the boundaries of the system and the applicable trust services criteria.

The documented perimeter defining which infrastructure, applications, personnel, processes, and data are inside the scope of the SOC 2 examination and which are excluded, with rationale for exclusions.

The process of determining which systems, locations, trust services categories, and controls fall within a SOC 2 engagement, driven by customer commitments, contracts, risk, and materiality.

A structured comparison of the entity's current controls and documentation against the applicable trust services criteria to identify missing or under-designed controls before the examination period begins.

The process of identifying threats to the achievement of trust services objectives, estimating likelihood and impact, and determining which risks require treatment through controls.

A maintained record of identified risks with owners, likelihood and impact ratings, linked controls, and treatment status, used as evidence that risk assessment occurs and is monitored.

The specification of a control's nature, timing, and extent so that, if performed as described, it would reasonably address the identified risk and satisfy the related criterion.

The actual deployment and operation of a designed control within the environment, evidenced by configuration settings, logs, approvals, or other artifacts showing it operated during the period.

A specific policy, procedure, or technical mechanism that helps ensure management directives are carried out and risks are mitigated, such as approvals, reconciliations, reviews, or automated restrictions.

A control intended to stop an error or unauthorized event before or as it occurs, for example access restrictions, segregation of duties, or mandatory approval workflows.

A control designed to identify errors, exceptions, or unauthorized activity after they occur, such as log monitoring, reconciliation, or periodic access reviews.

A control performed by a person through review, approval, or reconciliation, which requires evidence of performance such as a signed review, ticket comment, or dated checklist.

A control executed by system configuration or code without human intervention, such as enforced password policy, automated alerting, or system-generated exception reports.

Documentation demonstrating that a control was designed and operated during the examination period, such as screenshots, logs, tickets, approvals, or reports, which must be sufficient, relevant, and reliable.

The complete set of occurrences of a control during the examination period from which a sample is selected; completeness of the population is itself a key audit consideration.

Selecting a subset of control occurrences to test when the population is large, using a documented methodology so results can support a conclusion about operating effectiveness.

The named individual accountable for performing or maintaining a specific control and for producing evidence on request, typically recorded in the control matrix.

A mapping document linking each trust services criterion to the controls that address it, including control description, owner, frequency, type, and evidence source.

Controls that the service organization assumes user entities have implemented for the overall control environment to be effective, disclosed in the report so customers can assess their own responsibilities.

Controls expected to be performed by a subservice organization, disclosed when the service organization uses the carve-out method rather than the inclusive method.

A presentation in which the service organization excludes the subservice organization's controls from its own description and control testing, disclosing instead the complementary controls it relies upon.

A presentation in which the subservice organization's relevant controls are included within the service organization's system description and tested as part of the engagement.

A SOC 2 report expressing an opinion on the fairness of the system description and the suitability of control design at a specified date, without testing operating effectiveness over a period.

A SOC 2 report covering a period that opines on description fairness, design suitability, and operating effectiveness of controls, supported by testing of controls throughout the period.

Whether a control operated as designed consistently throughout the examination period, tested through inspection, observation, inquiry, or reperformance rather than design review alone.

A management-issued letter covering the gap between the end of a SOC 2 report period and a later date, confirming whether controls changed and often used by customers during that interval.

An auditor's conclusion that, except for specified matters, the description is fairly presented or controls were suitably designed and operating effectively, with exceptions described in the report.

A deviation identified when a tested control did not operate as described, which must be evaluated for cause, impact, and whether it constitutes a deficiency affecting the auditor's opinion.

A documented set of actions, owners, and target dates to correct a control gap or exception, tracked to completion and often shared with customers or auditors.

Ongoing automated or manual oversight of controls and compliance status between examinations, enabling early detection of drift and reducing last-minute evidence gathering.