SOC 2 Trust Services Criteria (TSC) Checklist
By Het Mehta
Source: Based on AICPA Trust Services Criteria (TSC) for Security, Availability, Processing Integrity, Confidentiality, and Privacy (2017 revision).
Disclaimer: This checklist is for informational and tracking purposes only. Control descriptions are paraphrased. Implementation examples and risks are illustrative. Always consult the official AICPA TSC documentation and qualified professionals for definitive guidance and interpretation specific to your organization's context. This tool does not constitute legal or compliance advice.
| Done | ID | Control Title | Control Description (Paraphrased) | Implementation Example | Risk Mitigated |
|---|---|---|---|---|---|
| Security (Common Criteria - CC Series) | |||||
| CC1: Control Environment | |||||
| CC1.1 | Commitment to Integrity and Ethical Values | The entity demonstrates a commitment to integrity and ethical values. | Publishing a Code of Conduct, regular ethics training, whistleblower hotline, tone at the top emphasizing ethical behavior. | Fraud, reputational damage, non-compliance due to unethical behavior. | |
| CC1.2 | Board Oversight Independence | The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control. | Independent board members, regular board meetings with documented minutes, audit committee overseeing internal controls and external audits. | Lack of effective oversight, management override of controls, strategic misalignment. | |
| CC1.3 | Management Establishes Structure, Authority, and Responsibility | Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives. | Defined organizational chart, documented roles and responsibilities (RACI matrix), clear reporting lines, delegation of authority policies. | Confusion over roles, lack of accountability, inefficient operations, unauthorized actions. | |
| CC1.4 | Commitment to Attract, Develop, and Retain Competent Individuals | The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. | Job descriptions with required competencies, structured hiring process, performance reviews, training and development programs, succession planning. | Skill gaps, operational errors, inability to meet objectives due to lack of competent personnel. | |
| CC1.5 | Holding Individuals Accountable | The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives. | Performance evaluations linked to control responsibilities, disciplinary actions for control failures, clear communication of expectations. | Lack of ownership for controls, repeated control failures, poor control environment. | |
| CC2: Communication and Information | |||||
| CC2.1 | Use of Relevant, Quality Information | The entity obtains or generates and uses relevant, quality information to support the functioning of internal control. | Using system logs for monitoring, generating performance reports, data validation checks, defining information requirements for control operation. | Poor decision-making, ineffective control operation due to inaccurate or incomplete information. | |
| CC2.2 | Internal Communication | The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control. | Internal newsletters, policy portals, all-hands meetings, team meetings discussing control responsibilities, documented procedures. | Misunderstanding of roles and responsibilities, inconsistent application of controls, lack of awareness of policies. | |
| CC2.3 | External Communication | The entity communicates with external parties regarding matters affecting the functioning of internal control. | Communicating security policies to vendors, notifying customers of privacy policy updates, reporting breaches as required by law, auditor communications. | Failure to meet external obligations, reputational damage, legal/regulatory non-compliance. | |
| CC3: Risk Assessment | |||||
| CC3.1 | Specifying Suitable Objectives | The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives. | Defining clear service commitments (SLAs), setting security objectives (e.g., RTO/RPO), establishing compliance goals based on regulations. | Inability to identify relevant risks, misalignment between controls and objectives. | |
| CC3.2 | Identification and Analysis of Risks | The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed. | Formal risk assessment process (e.g., annually), threat modeling, vulnerability assessments, considering internal/external factors, risk register. | Failure to identify significant threats/vulnerabilities, ineffective risk response, unexpected business disruptions. | |
| CC3.3 | Assessment of Fraud Risk | The entity considers the potential for fraud in assessing risks to the achievement of objectives. | Specific fraud risk assessment workshops, analyzing incentives/pressures/opportunities for fraud, considering risks of asset misappropriation and fraudulent reporting. | Undetected fraud, financial loss, reputational damage. | |
| CC3.4 | Identification and Analysis of Significant Changes | The entity identifies and assesses changes in the internal and external environment that could significantly impact the system of internal control. | Monitoring regulatory changes, assessing impact of new technologies, reviewing changes in business model or leadership, updating risk assessments based on changes. | Outdated controls, failure to adapt to new risks, non-compliance with new requirements. | |
| CC4: Monitoring Activities | |||||
| CC4.1 | Ongoing and/or Separate Evaluations | The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. | Regular internal audits, continuous monitoring tools (SIEM, IDS/IPS), management reviews of control performance, periodic vulnerability scans. | Undetected control failures, ineffective internal control system over time. | |
| CC4.2 | Communication of Deficiencies | The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate. | Formal process for reporting audit findings, tracking remediation of deficiencies, escalating significant issues, regular reporting to management/board. | Unremediated control weaknesses, repeated failures, significant undetected issues impacting objectives. | |
| CC5: Control Activities | |||||
| CC5.1 | Selection and Development of Control Activities | The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. | Designing specific controls based on risk assessment (e.g., implementing MFA based on access risk), documenting control procedures, segregation of duties analysis. | Unmitigated risks, ineffective or inefficient controls, failure to achieve objectives. | |
| CC5.2 | Selection and Development of General Controls over Technology | The entity selects and develops general control activities over technology to support the achievement of objectives. | Implementing controls over infrastructure (network security), security management (vulnerability management), technology acquisition/development/maintenance (change management, SDLC). | Technology failures, security breaches, unreliable systems impacting service delivery. | |
| CC5.3 | Deployment of Control Activities Through Policies and Procedures | The entity deploys control activities through policies that establish what is expected and procedures that put policies into action. | Documented Acceptable Use Policy, Information Security Policy, Incident Response Plan, step-by-step procedures for tasks like user onboarding or server patching. | Inconsistent application of controls, lack of clarity on expectations, control failures due to poor execution. | |
| CC6: Logical and Physical Access Controls | |||||
| CC6.1 | Logical Access Security | The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity’s objectives. | Using Identity and Access Management (IAM) systems, role-based access control (RBAC), firewalls, VPNs, intrusion detection/prevention systems (IDS/IPS). | Unauthorized access to systems/data, data breaches, system compromise. | |
| CC6.2 | Issuance and Removal of Credentials | Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized. | Formal user registration/approval process, timely deprovisioning of accounts upon termination/role change, automated workflows for onboarding/offboarding. | Unauthorized access by former employees/users, orphaned accounts, credential misuse. | |
| CC6.3 | Authorization and Modification of Access Rights | The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of segregation of duties and least privilege. | Access request/approval forms/workflows, principle of least privilege enforcement, periodic access reviews, RBAC implementation, segregation of duties matrix. | Excessive privileges leading to unauthorized actions/data access, fraud due to lack of segregation of duties. | |
| CC6.4 | Restriction of Physical Access | The entity restricts physical access to facilities and protected information assets (for example, data center facilities, backup media, and other sensitive documents) to authorized personnel to meet the entity’s objectives. | Badged access to data centers/offices, security guards, visitor logs, locked server racks, secure disposal of media/documents, surveillance cameras. | Physical theft of assets, unauthorized physical access leading to system compromise or data exposure. | |
| CC6.5 | Disposal of Protected Information Assets | The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished and is no longer required to meet the entity’s objectives. | Secure data wiping procedures (e.g., NIST 800-88), physical destruction of media (shredding, degaussing), documented disposal process and logs. | Data leakage from improperly disposed assets, non-compliance with data destruction requirements. | |
| CC6.6 | Prevention and Detection of Unauthorized Access (External) | The entity implements logical access security measures to protect against threats from sources outside its system boundaries. | Firewalls configured with deny-all default rules, IDS/IPS monitoring external connections, VPNs for remote access, network segmentation, DDoS mitigation services. | External attacks compromising the network perimeter, unauthorized access from the internet. | |
| CC6.7 | Restriction of Information Transmission | The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal to meet the entity’s objectives. | Data Loss Prevention (DLP) tools, encryption of data in transit (TLS/SSL, VPNs), controls over removable media, email filtering, egress traffic monitoring. | Data exfiltration, unauthorized sharing of sensitive information, data interception during transmission. | |
| CC6.8 | Prevention of Malicious Software | The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives. | Endpoint anti-malware solutions (EPP/EDR), email/web filtering for malicious content, application whitelisting, regular vulnerability scanning, user awareness training. | Malware infections (ransomware, viruses, spyware), system compromise, data loss/theft. | |
| CC7: System Operations | |||||
| CC7.1 | Detection and Monitoring (Changes, Security Events) | To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to infrastructure, data, and software resulting from processing or system activities, and (2) security events. | SIEM systems collecting/analyzing logs, file integrity monitoring (FIM), vulnerability scanning tools (internal/external), IDS/IPS alerts, network traffic analysis, configuration monitoring. | Undetected security incidents, unmanaged vulnerabilities, unauthorized changes leading to compromise or outages. | |
| CC7.2 | Monitoring for Anomalies and Security Events | The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events. | Regular vulnerability scanning (authenticated/unauthenticated), penetration testing, patch management program, vulnerability prioritization based on risk, secure configuration hardening, SIEM rule tuning for anomaly detection. | Exploitation of known vulnerabilities, system compromise, service disruption, undetected anomalies. | |
| CC7.3 | Incident Response Evaluation | When anomalies or suspicious events are detected, the entity evaluates them to determine if they constitute security incidents. | Defined incident response plan (IRP), incident classification/prioritization process, security analyst review of alerts, correlation of events in SIEM. | Failure to recognize or classify security incidents correctly, delayed response. | |
| CC7.4 | Incident Response Plan Execution | A security incident response plan is in place to guide the response to security incidents. The plan is tested, and response personnel understand their responsibilities in executing the plan. | Documented IRP covering containment, eradication, recovery phases; designated incident response team; regular tabletop exercises or simulations; post-incident reviews. | Ineffective incident handling, prolonged impact of incidents, failure to recover systems/data properly. | |
| CC7.5 | Incident Management and Recovery | The entity identifies, develops, and implements activities to recover from identified security incidents. | Defined communication channels within IRP, procedures for notifying internal stakeholders/management/legal, external communication plan (customers, regulators), recovery steps defined in IRP. | Confusion during incidents, failure to notify required parties, reputational damage from poor communication, slow recovery. | |
| CC8: Change Management | |||||
| CC8.1 | Change Management Process | The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. | Formal change management policy/process, change request forms, Change Advisory Board (CAB) reviews, testing procedures (unit, integration, UAT), rollback plans, documentation updates, separation of development/testing/production environments. | Unauthorized changes, service disruptions due to poorly tested changes, security vulnerabilities introduced by changes, configuration drift. | |
| CC9: Risk Mitigation | |||||
| CC9.1 | Risk Identification and Mitigation (Business Disruptions, Vendors) | The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions and risks associated with the use of vendors and business partners. | Business Impact Analysis (BIA), developing Business Continuity/Disaster Recovery (BC/DR) plans, vendor risk assessment process, contractual agreements with vendors including security/compliance requirements. | Inability to recover from disruptions, risks introduced by third parties (vendor breaches, non-performance). | |
| CC9.2 | Business Continuity and Disaster Recovery Execution | The entity assesses and manages risks associated with threats and vulnerabilities that may result in business disruptions to enable the entity to meet its objectives. | Documented BCP/DRP, identification of critical systems/processes, defined RTO/RPO, backup and recovery procedures, alternate site arrangements, regular testing of plans (aligned with A1.3). | Prolonged outages, inability to meet service commitments during disruptions, data loss. | |
| Availability (A Series) | |||||
| A1: Availability Controls | |||||
| A1.1 | Performance Monitoring and Capacity Planning | The entity monitors system performance and capacity to maintain availability in line with objectives and service commitments. | System monitoring tools (CPU, memory, disk, network), capacity planning reviews and forecasting, load testing, performance alerting thresholds. | Service degradation or outages due to resource exhaustion, failure to meet performance SLAs. | |
| A1.2 | Disaster Recovery Infrastructure and Processes | The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its availability objectives. | Regular data backups (full, incremental, differential), offsite backup storage, documented recovery procedures, DR site/infrastructure, regular DR testing and validation. | Data loss, inability to recover systems after a disaster, failure to meet RTO/RPO. | |
| A1.3 | Testing of Business Resiliency / Recovery Plans | The entity tests recovery plan procedures supporting system recovery to meet its availability objectives. | Documented DR test plans, execution of DR tests (walkthrough, simulation, full interruption), documenting test results and lessons learned, updating plans based on tests. | Ineffective recovery plans, unexpected issues during a real disaster, prolonged recovery times. | |
| Processing Integrity (PI Series) | |||||
| PI1: Processing Integrity Controls | |||||
| PI1.1 | Definition of Processing Activities and Specifications | The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services. | Documented system specifications, data dictionaries defining inputs/outputs, process flow diagrams, service descriptions communicated to customers. | Misunderstanding of system functionality, incorrect data usage, processing errors due to ambiguity. | |
| PI1.2 | Implementation of Procedures for Complete, Accurate, Timely Processing | The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity’s objectives. | Input validation checks, data type/format enforcement, reconciliation procedures, batch processing controls, transaction logging, error handling routines. | Inaccurate data processing, incomplete transactions, processing delays, data corruption. | |
| PI1.3 | Definition of Processing Specifications | The entity defines processing specifications necessary to meet the entity’s objectives. | Documenting algorithms, calculation logic, data transformation rules, workflow steps, system configuration parameters related to processing. | Incorrect system behavior, inaccurate results, failure to meet processing requirements. | |
| PI1.4 | Monitoring of Inputs, Processing, and Outputs | The entity monitors processing activities, including inputs and outputs, for completeness, accuracy, and timeliness to determine that they are occurring as specified to meet the entity’s objectives. | Input/output reconciliation reports, monitoring dashboards for processing queues/times, automated alerts for processing errors or delays, review of exception logs. | Undetected processing errors, incomplete processing runs, delays impacting service delivery. | |
| PI1.5 | Correction of Processing Errors | The entity corrects errors and omissions in processing identified in a timely manner to meet the entity’s objectives. | Defined error correction procedures, reprocessing capabilities, logs of corrected errors, timely investigation and resolution of processing issues. | Persistent data inaccuracies, incorrect reporting, customer dissatisfaction due to uncorrected errors. | |
| Confidentiality (C Series) | |||||
| C1: Confidentiality Controls | |||||
| C1.1 | Identification and Protection of Confidential Information | The entity identifies and maintains confidential information to meet the entity’s objectives related to confidentiality. | Data classification policy, identifying confidential data (e.g., PII, financial data, trade secrets), data discovery tools, marking confidential documents/data, applying access controls (CC6.3) and encryption. | Failure to protect sensitive data appropriately, accidental disclosure, non-compliance with confidentiality agreements. | |
| C1.2 | Disposal of Confidential Information | The entity disposes of confidential information to meet the entity’s objectives related to confidentiality. | Secure data destruction policy (aligned with CC6.5), using secure wipe utilities, physical destruction of media containing confidential data, procedures for de-identifying data before disposal if applicable. | Data leakage from improperly disposed assets containing confidential information, breach of confidentiality agreements. | |
| Privacy (P Series) - Note: Often based on GAPP | |||||
| P1: Notice and Communication of Privacy Practices | |||||
| P1.1 | Privacy Notice Content and Communication | The entity provides notice to data subjects about its privacy practices to meet the entity’s objectives related to privacy. The notice is updated and communicated to data subjects in a timely manner for changes to the entity’s privacy practices. | Clear, comprehensive, easily accessible privacy policy/notice detailing data collected, purpose, sharing, retention, rights; process for updating and communicating policy changes. | Non-compliance with privacy regulations (GDPR, CCPA), lack of transparency, data subject complaints. | |
| P2: Choice and Consent | |||||
| P2.1 | Obtaining Choice and Consent | The entity describes the choices available to the data subject and obtains implicit or explicit consent with respect to the collection, use, and disclosure of personal information to meet the entity’s objectives related to privacy. Consent is obtained from data subjects or other authorized persons, including updates to consent, in a timely manner. | Mechanisms for obtaining consent (checkboxes, forms), clear explanation of choices (opt-in/opt-out), managing consent records, process for withdrawing consent. | Processing personal data without valid consent, non-compliance with privacy laws, loss of data subject trust. | |
| P3: Collection | |||||
| P3.1 | Limiting Collection of Personal Information | The entity collects personal information only for the purposes identified in the notice to meet the entity’s objectives related to privacy. | Data minimization practices, collecting only necessary data fields, reviewing data collection points against stated purposes in the privacy notice. | Collecting excessive personal data, violating data minimization principles, increased risk exposure. | |
| P4: Use, Retention, and Disposal | |||||
| P4.1 | Limiting Use, Retention, and Disposal | The entity limits the use, retention, and disposal of personal information to meet the entity’s objectives related to privacy. | Using data only for disclosed purposes, data retention policy/schedule, secure disposal procedures (aligned with C1.2), anonymization/pseudonymization techniques where appropriate. | Using data for unconsented purposes, retaining data longer than necessary increasing risk, data leakage from improper disposal. | |
| P4.2 | Updating or Correcting Personal Information | The entity updates or corrects personal information consistent with the purposes for which it is processed, as necessary, to meet the entity’s objectives related to privacy. | Procedures for data subjects to request corrections, processes to update data based on reliable sources, maintaining data accuracy relevant to its use. | Inaccurate data leading to incorrect decisions or processing, failure to comply with data subject rights. | |
| P5: Access | |||||
| P5.1 | Providing Access to Personal Information | The entity provides data subjects with access to their personal information for review and correction (including updates) to meet the entity’s objectives related to privacy. | Data Subject Access Request (DSAR) process, identity verification procedures for requesters, mechanisms to provide data extracts, process for handling correction requests. | Failure to comply with data subject access rights under privacy laws, inability for users to correct inaccurate data. | |
| P6: Disclosure and Notification | |||||
| P6.1 | Disclosure to Third Parties | The entity discloses personal information to third parties only for the purposes identified in the notice and with the implicit or explicit consent of the data subject to meet the entity’s objectives related to privacy. | Vendor agreements with data processing clauses, ensuring third parties adhere to privacy commitments, disclosing sharing practices in privacy notice, obtaining consent for sharing where required. | Unauthorized sharing of personal data, non-compliance with privacy regulations regarding third-party transfers. | |
| P6.2 | Notification of Changes and New Purposes | The entity notifies data subjects of any changes to its privacy practices or the intended use of personal information before the change takes place or the new use occurs, and obtains implicit or explicit consent in a timely manner to meet the entity’s objectives related to privacy. | Process for communicating privacy policy updates, obtaining fresh consent for new data uses not covered by original consent. | Using data for new purposes without consent, violating data subject expectations and privacy laws. | |
| P6.3 | Notification of Breach and Incidents | The entity notifies affected data subjects, regulators, and others, as necessary, of security incidents or breaches involving personal information in accordance with its objectives related to privacy. | Incident response plan including breach notification procedures, understanding legal requirements for notification timelines/content, communication templates. | Failure to notify required parties after a breach, legal/regulatory penalties, reputational damage. | |
| P7: Quality | |||||
| P7.1 | Maintaining Personal Information Quality | The entity maintains personal information as needed for the purposes stated in the notice and for which the personal information is processed to meet the entity’s objectives related to privacy. | Data validation rules, periodic data quality checks, processes for updating information based on reliable sources (aligned with P4.2). | Inaccurate data leading to incorrect processing or decisions impacting data subjects. | |
| P8: Monitoring and Enforcement | |||||
| P8.1 | Monitoring Compliance and Addressing Complaints | The entity monitors compliance with its privacy policies and procedures and has procedures to address privacy-related inquiries, complaints, and disputes to meet the entity’s objectives related to privacy. | Designated privacy officer/team, internal privacy audits, process for handling data subject inquiries/complaints, dispute resolution mechanism, tracking and reporting on privacy compliance. | Unaddressed privacy violations, recurring non-compliance, data subject dissatisfaction, regulatory fines. | |
SOC 2 TSC Hierarchy Map
graph TD
SOC2[SOC 2 Trust Services Criteria] --> SEC(Security / Common Criteria);
SOC2 --> AVA(Availability);
SOC2 --> PI(Processing Integrity);
SOC2 --> CON(Confidentiality);
SOC2 --> PRIV(Privacy);
SEC --> CC1(CC1: Control Environment);
SEC --> CC2(CC2: Communication & Information);
SEC --> CC3(CC3: Risk Assessment);
SEC --> CC4(CC4: Monitoring Activities);
SEC --> CC5(CC5: Control Activities);
SEC --> CC6(CC6: Logical & Physical Access);
SEC --> CC7(CC7: System Operations);
SEC --> CC8(CC8: Change Management);
SEC --> CC9(CC9: Risk Mitigation);
AVA --> A1(A1: Availability Controls);
PI --> PI1(PI1: Processing Integrity Controls);
CON --> C1(C1: Confidentiality Controls);
PRIV --> P1(P1: Notice & Communication);
PRIV --> P2(P2: Choice & Consent);
PRIV --> P3(P3: Collection);
PRIV --> P4(P4: Use, Retention & Disposal);
PRIV --> P5(P5: Access);
PRIV --> P6(P6: Disclosure & Notification);
PRIV --> P7(P7: Quality);
PRIV --> P8(P8: Monitoring & Enforcement);
style SOC2 fill:#f9f,stroke:#333,stroke-width:2px;
style SEC fill:#ccf;
style AVA fill:#cfc;
style PI fill:#ffc;
style CON fill:#fcc;
style PRIV fill:#cff;
This map shows the high-level relationship between Trust Service Principles and their main control categories.