Legal, Risk, and Compliance practice questions

A binding corporate rule approved by the US Department of Commerce

Why it fails: BCRs are for intra-group transfers and approved by EU DPAs, not the US Department of Commerce.

An adequacy decision by the US Federal Trade Commission

Why it fails: Adequacy decisions are made by the European Commission, not the FTC.

A data processing agreement solely between the cloud provider and the data subjects

Why it fails: Data processing agreements are between controller and processor, not with data subjects.

Annual penetration testing of the SaaS provider's infrastructure

Why it fails: Penetration testing probes exploitable vulnerabilities in the provider's infrastructure; it does not evidence change management, logical access or processing integrity over the ledger. It is tempting as an assurance activity, and would be correct for validating the security posture of externally exposed cloud services.

Daily backups of the financial database

Why it fails: Backups restore availability after loss or corruption; they do not prevent or detect unauthorised modification of ledger entries, which is what SOX integrity demands. Backups are tempting because they are a standard IT general control, and they would be the right answer where the scenario's risk was data destruction or ransomware recovery rather than financial-reporting accuracy.

Implementation of multi-factor authentication for all users

Why it fails: Access control is important but change management is more critical for the integrity of the general ledger.

Service Organization Control (SOC) 2 report

Why it fails: SOC 2 is a voluntary audit report, not a requirement of PCI DSS.

Business Associate Agreement (BAA)

Why it fails: BAA is for HIPAA compliance.

Data Processing Agreement (DPA)

Why it fails: DPA is for GDPR, not PCI DSS.

Tier 4: Nonexistent

Why it fails: Only three tiers exist.

Tier 1: Self-assessment

Why it fails: Tier 1 is self-assessment using the CAIQ.

Tier 3: Continuous monitoring

Why it fails: Tier 3 involves ongoing monitoring.

The provider must sign a Business Associate Agreement

Why it fails: BAA is for HIPAA, not PCI.

The cloud provider must be a Level 1 service provider

Why it fails: Level classification is based on transaction volume, not a requirement.

Binding Corporate Rules (BCRs)

Why it fails: BCRs are for intra-group transfers, not specifically for transfers to a cloud provider in a third country.

Adequacy decision by the European Commission

Why it fails: Singapore does not have an adequacy decision from the EU.

Data Protection Agreement (DPA) with the cloud provider

Why it fails: A DPA is required between controller and processor but does not alone legitimize cross-border transfers.

Multi-factor authentication

Why it fails: Authentication is part of access controls, but change management is typically more emphasized in SOX audits.

Data encryption at rest

Why it fails: Encryption is important but not the most critical SOX control; access and change management are key.

Automated backup procedures

Why it fails: Backups are important but not the primary focus of SOX IT general controls.

Tier 4: Auditing

Why it fails: There is no Tier 4 in CSA STAR.

Tier 3: Continuous monitoring

Why it fails: Tier 3 involves continuous monitoring based on NIST standards.

Tier 1: Self-assessment

Why it fails: Tier 1 is a self-assessment using the CAIQ.

Network perimeter controls

Why it fails: Network perimeter may be shared or customer responsibility depending on service model.

Application security for custom code

Why it fails: Application security for custom code is typically the customer's responsibility.

Encryption key management

Why it fails: Encryption key management may be shared or customer responsibility, but not always mandated in PCI DSS Appendix A3.

Adequacy decision by the US

Why it fails: The US does not have an adequacy decision from the EU (the Privacy Shield was invalidated).

Data Subject's explicit consent

Why it fails: Consent may be used but is difficult to rely upon for ongoing transfers and can be withdrawn.

Binding Corporate Rules (BCRs)

Why it fails: BCRs are for intra-group transfers, not for transfers to a third-party cloud provider.

Data encryption at rest

Why it fails: Encryption is important but not specifically a SOX ITGC.

Multi-factor authentication

Why it fails: MFA is a security best practice but not a specific SOX ITGC requirement.

Annual penetration testing

Why it fails: Penetration testing is not a required ITGC for SOX.

Right to transfer data to a third country

Why it fails: Right to transfer data to a third country is not a standalone data subject right under GDPR; transfers are subject to safeguards but not a right of the data subject.

Right to portability

Why it fails: Right to portability is a data subject right under GDPR Article 20, but it is not selected as one of the three specific rights in this question.

The company must delete all personal data within 30 days of collection.

Why it fails: GDPR does not mandate a specific retention period; it requires data to be kept no longer than necessary.

The company is not subject to GDPR because its headquarters and the cloud server are located outside the EU.

Why it fails: GDPR has extraterritorial scope; location of processing does not exempt compliance.

The company must obtain explicit consent from each data subject before processing their data.

Why it fails: Consent is one lawful basis but not always required; other bases may apply. The statement is too absolute.

The company must sign a Business Associate Agreement (BAA) with the cloud provider.

Why it fails: BAA is for HIPAA, not PCI DSS. PCI DSS requires a shared responsibility matrix.

The company must conduct its own on-site audit of the cloud provider's data centers.

Why it fails: On-site audits may not be practical or permitted; assessment via SAQ or by a QSA is typical.

The company must ensure that the cloud provider encrypts all cardholder data at rest and in transit.

Why it fails: Encryption is required, but the primary step is to validate the provider's compliance status.

Service Level Agreement (SLA) for availability

Why it fails: SLA is about performance during the contract, not exit.

Non-disclosure agreement (NDA)

Why it fails: NDA protects confidentiality but not data access at exit.

Right to audit clause

Why it fails: Audit is for ongoing oversight, not exit.

Enforcing role-based access control with least privilege

Why it fails: Access control is important but not the only ITGC; the question asks for two essential controls.

Implementing encryption for data at rest and in transit

Why it fails: Encryption is a security control but not a specific SOX ITGC requirement.

Configuring automated backups with daily snapshots

Why it fails: Backups are important for disaster recovery but not a specific SOX ITGC.

Implement data portability features to export PHI

Why it fails: Data portability is not a HIPAA requirement; it is more relevant to GDPR.

Conduct quarterly penetration testing on the cloud infrastructure

Why it fails: Penetration testing is not a specific HIPAA requirement, though it may be part of risk analysis.

Adequacy decision for the United States

Why it fails: The EU-US Data Privacy Framework is a partial adequacy decision, but it only applies to US organizations that self-certify under the framework. Since the provider is not certified, the adequacy decision does not apply. Relying on it would be invalid and leave the transfer without a legal basis.

Binding Corporate Rules (BCRs) alone

Why it fails: BCRs are approved by a supervisory authority for intra-group transfers within a corporate group. They are not suitable for transfers to an external cloud provider that is a separate legal entity. The scenario involves a customer-provider relationship, not intra-group data flows, so BCRs would not provide a valid transfer mechanism here.

Derogation for explicit consent from data subjects

Why it fails: Article 49 derogations, such as explicit consent, are intended for occasional, non-repetitive transfers. Using them for systematic cloud processing of personal data would not meet the strict necessity and proportionality criteria. This approach is unsustainable for ongoing operations and likely non-compliant with GDPR's transfer requirements.

Binding Corporate Rules (BCRs) for intra-group transfers

Why it fails: BCRs are designed for multinational corporations to transfer data within their own corporate group. Here, the transfer is to a cloud region in the US, which may involve a cloud provider outside the company's group. BCRs would not cover the cloud provider unless it is part of the same group, so they are not the best fit.

Derogation for explicit consent under Article 49

Why it fails: Article 49 derogations, such as explicit consent, are meant for occasional and non-repetitive transfers. Using them for routine analytics on customer data would not be appropriate because the transfer is systematic and large-scale. Derogations are also interpreted narrowly and do not provide a long-term compliance solution for ongoing cloud processing.

Privacy Shield certification of the cloud provider

Why it fails: The EU-U.S. Privacy Shield framework was invalidated by the Court of Justice of the European Union in the Schrems II ruling. It is no longer a valid mechanism for transferring personal data from the EU to the US. Relying on it would leave the company non-compliant with GDPR transfer requirements.

PCI DSS Attestation of Compliance (AOC)

Why it fails: The AOC is a form that the provider completes to attest to its PCI DSS compliance status. While it indicates which requirements the provider meets, it does not explicitly detail the division of responsibilities between the provider and the customer. The customer needs a document that maps controls to each party, so the AOC alone is insufficient.

PCI DSS Report on Compliance (ROC)

Why it fails: The ROC is a detailed report prepared by a Qualified Security Assessor (QSA) that documents the provider's compliance with PCI DSS. While it contains extensive information, it is focused on the provider's environment and does not explicitly delineate which controls the customer must implement. The customer needs a responsibility matrix, not just the provider's ROC.

PCI DSS Self-Assessment Questionnaire (SAQ)

Why it fails: The SAQ is a validation tool for merchants and service providers to self-assess their PCI DSS compliance. It is completed by the entity itself and does not provide a mapping of responsibilities between a cloud provider and its customer. The customer would complete its own SAQ, but it would not clarify the provider's responsibilities.