3.0 Considerations for System and Organization Controls (SOC) Engagements ISC Practice Quiz

• A. Security, Availability, Processing Integrity, Confidentiality, Privacy
• B. Confidentiality, Integrity, Authentication, Authorization, Non-repudiation
• C. Governance, Risk, Compliance, Operations, Reporting
• D. Planning, Designing, Operating, Monitoring, Reviewing

The AICPA Trust Services Criteria (TSC), used in SOC 2 engagements, are organized into five categories: (1) Security (CC. Common Criteria): the system is protected against unauthorized access, use, or modification, the only category required for all SOC 2 engagements; forms the foundational 'Common Criteria' that all other categories build upon; organized around COSO's 17 principles of internal control; (2) Availability (A): the system is available for operation and use as committed; covers system performance, capacity, and business continuity; (3) Processing Integrity (PI): system processing is complete, valid, accurate, timely, and authorized; (4) Confidentiality (C): information designated as confidential is protected as committed; (5) Privacy (P): personal information is collected, used, retained, disclosed, and disposed of in conformity with commitments and applicable law. Service organizations choose which categories to include based on their commitments to user entities and applicable requirements.

• A. SOC 2, the Security Trust Services criteria cover all controls relevant to financial reporting
• B. SOC 3, a publicly available general-use report is needed so all stakeholders can review the payroll processor's controls
• C. SOC 1, a report specifically designed to address controls at a service organization that are relevant to user entities' internal control over financial reporting (ICFR), used by user entities and their auditors for financial statement audit purposes
• D. SOC for Cybersecurity, the cybersecurity risk management program report is appropriate when user entities are concerned about cybersecurity affecting financial systems

SOC 1 (SSAE 18 AT-C Section 320) is specifically designed for: service organizations whose services affect user entities' financial reporting; user entities and their independent auditors who need to understand and test ICFR at service organizations. For a payroll processor: payroll processing affects the user entity's payroll expense, accrued liabilities, and related financial statement accounts; the user entity's external auditor must understand whether payroll calculations, disbursements, and reporting are controlled effectively; a SOC 1 Type 2 report provides the detailed description of controls and service auditor test results needed to evaluate ICFR at the payroll processor. This is a direct SOX Section 404 use case.

• A. Commitment 1 corresponds to Availability; Commitment 2 corresponds to Processing Integrity; Commitment 3 corresponds to Confidentiality, each commitment maps to the Trust Services category specifically designed to address that type of control objective
• B. All commitments fall under the Security category, all Trust Services criteria are subsets of security
• C. Commitment 1 corresponds to Processing Integrity; Commitment 2 corresponds to Availability; Commitment 3 corresponds to Privacy, mapping commitments to categories requires reversing availability and processing integrity
• D. Commitment 3 corresponds to Privacy because employee salary data is personal information, the other commitments fall under Security

Direct commitment-to-category mapping: Commitment 1 (99.9% availability) → Availability (A): the Availability category covers whether the system is accessible and performing as committed during agreed service hours; uptime percentages, SLAs, and business continuity arrangements are Availability criterion subject matter. Commitment 2 (accurate and complete payroll calculations) → Processing Integrity (PI): the Processing Integrity category covers whether system processing is complete, valid, accurate, timely, and authorized; payroll calculation accuracy (correct gross pay, withholding, net pay) is precisely what Processing Integrity addresses. Commitment 3 (salary data not disclosed to unauthorized parties) → Confidentiality (C): the Confidentiality category covers whether information designated as confidential (employee salary data is inherently confidential) is protected from unauthorized disclosure. Note: Security (CC) would also be included as the mandatory foundational category in any SOC 2 engagement.

• A. SOC 1 Type 2, the most comprehensive report providing detailed control descriptions and test results suitable for all public marketing purposes
• B. SOC 2 Type 2, the detailed trust services controls report that provides specific control descriptions, testing procedures, and results for sophisticated user entity review
• C. SOC 3, a general-use, publicly shareable report containing the service auditor's opinion on whether the system met the applicable Trust Services Criteria, suitable for broad distribution without confidentiality restrictions
• D. SOC for Cybersecurity, the cybersecurity risk management program report is the appropriate publicly shareable format for cloud service providers

SOC 3 is specifically designed for general use and public distribution: (1) Content: service auditor's opinion on whether the service organization's controls met the applicable Trust Services Criteria; management's assertion about the effectiveness of controls; service organization's description of its system (brief, high-level); (2) No detailed control descriptions, test procedures, or exception details that require NDA protection; (3) Use case: marketing and public trust, organizations post SOC 3 reports on their websites as evidence of independent security assurance; prospective customers download it to confirm independent assessment exists before engaging in detailed SOC 2 review under NDA; (4) Relationship to SOC 2: organizations typically obtain SOC 2 Type 2 (detailed, restricted) and SOC 3 (summary, public) simultaneously, the SOC 3 is derived from the same engagement as the SOC 2.

• A. A SOC 2 Type 1 confirms that controls were suitably designed as of one month ago but provides no evidence that controls have actually operated effectively over any period, the customer cannot rely on it to conclude that the provider's controls would prevent breaches or maintain service quality over time; a Type 2 report covering at least 6 months is typically needed for meaningful assurance about operational control effectiveness
• B. No concern, a Type 1 report obtained last month is sufficient for all assurance purposes; report age is more important than report type
• C. The concern is that Type 1 reports are not issued by CPAs. Type 1 reports can be self-issued by the service organization without independent attestation
• D. A one-month-old report is too recent, SOC reports must be at least 12 months old before they provide meaningful historical assurance

The Type 1 limitation for operational assurance: (1) What Type 1 confirms: controls are suitably designed to meet the criteria as of the report date, the policies, procedures, and systems are set up appropriately; (2) What Type 1 does not confirm: controls have actually been followed by staff consistently; controls have operated effectively in practice (employees may know the right policy but not follow it); controls have been effective through various scenarios (system updates, staff turnover, increased transaction volume); (3) Operating effectiveness gap: a service organization could have perfect policies and procedures but if staff don't follow them, controls fail. Type 1 cannot detect this because it doesn't test operating effectiveness; (4) User entity implication: relying on a Type 1 for operational assurance is analogous to concluding that a company's financial controls are effective because it has a well-written internal control manual, the manual being good doesn't mean it was followed. For meaningful reliance, user entities and their auditors need a Type 2 report demonstrating that controls operated effectively over a defined period.

• A. The Common Criteria establish the baseline security and control environment requirements that apply across all categories, the supplemental criteria add category-specific requirements that address the unique aspects of each category (availability, processing integrity, confidentiality, or privacy) beyond the common foundation
• B. The Common Criteria replace the supplemental criteria, organizations need only satisfy Security criteria; the other four categories are optional additions with no relationship to the Common Criteria
• C. The supplemental criteria are more important than the Common Criteria, organizations can satisfy SOC 2 requirements by meeting supplemental criteria without addressing the Common Criteria
• D. The Common Criteria and supplemental criteria address different audiences, the Common Criteria apply to technical staff; supplemental criteria apply to management and governance

The Common Criteria (CC) relationship to supplemental criteria: (1) Common Criteria (CC1-CC9) cover the foundational security environment applicable to all engagements: control environment (tone at the top, organizational structure, values); communication and information; risk assessment; monitoring activities; control activities (logical access, physical access, change management, operations). These 17 principles are directly aligned with COSO Internal Control. Integrated Framework. (2) Supplemental criteria add category-specific requirements: Availability (A1): monitoring system capacity; maintaining backup and recovery capabilities; evaluating availability risks. Processing Integrity (PI1): policies defining authorized input, processing, and output; detecting and correcting processing errors. Confidentiality (C1): identifying and classifying confidential information; protecting it from unauthorized access. Privacy (P1-P8): notice/consent; data quality; monitoring and enforcement. (3) Relationship: an organization must satisfy CC criteria plus all applicable supplemental criteria for each included category, the Common Criteria are prerequisites, not alternatives.

• A. The SOC 1 Type 2, it is specifically designed to report on controls relevant to user entities' internal control over financial reporting; the IS auditor evaluating controls relevant to the financial statement audit should rely primarily on the SOC 1 because it addresses the controls that affect the client's financial reporting
• B. The SOC 2 Type 2, it covers more Trust Services categories and therefore provides broader assurance relevant to the financial audit
• C. Both reports are equally relevant, the auditor should average the findings from both reports to form an overall opinion on the cloud ERP provider's control effectiveness
• D. Neither report, IS auditors performing financial statement audits cannot rely on service organization reports and must perform all testing directly at the service organization

The SOC 1 vs. SOC 2 selection for financial audit purposes: SOC 1 (ICFR focus): designed specifically for service organizations whose services affect user entities' financial reporting; addresses the controls that the service organization has placed in operation to prevent or detect misstatements in user entity financial statements; for a cloud ERP: user access provisioning and deprovisioning; segregation of duties in financial transaction processing; change management over financial application code; data integrity controls for financial data; SOC 2 (operational security focus): addresses security, availability, processing integrity, confidentiality, and privacy of the service, important for information security assessments but not the primary reference for financial audit reliance; the IS auditor should use the SOC 1 Type 2 as the primary reference for ICFR evaluation, supplemented by SOC 2 for cybersecurity considerations relevant to the audit.

• A. SOC 2 categories should be selected based on the service organization's commitments and user entities' needs, the organization has made specific commitments (99.5% uptime, health record processing, insurance claim accuracy) that directly invoke Availability, Privacy, Processing Integrity, and Confidentiality; including only Security would produce a report that does not address the controls most relevant to user entities' concerns about the service
• B. The auditor should agree with management, minimizing SOC 2 scope always serves user entities' best interests by reducing the cost of the service organization's compliance program
• C. Regulations require all five Trust Services categories for any organization processing health information, there is no management discretion in category selection
• D. Including all five categories always produces the most valuable SOC 2 report, the auditor should recommend all five regardless of the service organization's specific commitments

Category selection rationale for this service organization: (1) Security (mandatory): foundational, required for any SOC 2; (2) Availability, 99.5% uptime commitment: the organization has a specific contractual SLA; user entities depend on availability for insurance claim processing; Availability category directly addresses whether the system meets its uptime commitments; (3) Processing Integrity, insurance claim processing: if the organization processes insurance claims on behalf of user entities, accuracy and completeness are critical; an inaccurate claim processing system creates direct financial harm to user entities; Processing Integrity addresses whether claims are processed correctly, completely, and timely; (4) Confidentiality, health records: patient health information is inherently confidential business information for the covered entity (user entity); Confidentiality criterion addresses whether the service organization protects designated confidential information; (5) Privacy, health records contain personal information: HIPAA-covered health data; the Privacy category addresses collection, use, retention, disclosure, and disposal of personal information; inclusion is appropriate when personal information is a significant part of the service. The report should reflect actual commitments, including only Security when Availability, PI, Confidentiality, and Privacy commitments exist leaves user entities without assurance on their most important concerns.