17.2 Privacy, Confidentiality, and Compliance Frameworks

Confidentiality Versus Privacy

Confidentiality concerns information the organization has committed to protect from unauthorized disclosure: customer contracts, pricing models, employee files, source code, trade secrets, or nonpublic financial data. Privacy concerns personal information (PI) and the rules for collecting, using, retaining, disclosing, and disposing of it. Personal information can be confidential, but not all confidential information is personal. This distinction is heavily tested because the two map to different Trust Services Criteria categories.

The exam tests the difference through a control objective. If a company promises customers that uploaded documents are visible only to authorized users, the emphasis is confidentiality. If the company collects consumer location data and must honor consent, access, correction, and deletion obligations and a published privacy notice, the emphasis is privacy.

Frameworks in the ISC Blueprint

Area II requires foundational knowledge of selected regulations, standards, and frameworks. You do not memorize every paragraph; you should know why each exists and how management uses it to design controls.

Data Life-Cycle Controls

Privacy and confidentiality controls should follow the data through its life cycle. At collection, the organization needs notice, consent where required, approved intake channels, and data minimization. During processing, it needs role-based access, segregation of duties, workflow controls, and monitoring. During storage, it needs encryption, key management, classification, backup protection, and retention rules. During transmission, it needs secure protocols such as TLS, certificate management, and transfer monitoring. At deletion, it needs defensible disposal, evidence of erasure, and procedures for legal holds.

• Encryption converts data into unreadable form without a key; protects data at rest and in transit.
• Tokenization substitutes a non-sensitive token for sensitive data such as a card number, with the real value held in a secure vault.
• Data obfuscation / masking scrambles values, ideal for development and test environments.
• Data Loss Prevention (DLP) monitors and can block unauthorized movement of sensitive data through email, endpoints, cloud storage, or the network.

Breach Implications

A breach is not only an IT event. It can trigger notification costs, regulatory fines (for example, GDPR penalties up to the greater of EUR 20 million or 4% of global annual revenue), litigation, lost customers, contract penalties, operational downtime, higher cyber-insurance premiums, and loss of trust. For a CPA, those consequences can affect risk assessment, disclosure, going-concern analysis, control-deficiency conclusions, and audit evidence.

SOC 2 Testing Lens

For SOC 2, confidentiality and privacy controls are evaluated against service commitments, system requirements, and the Trust Services Criteria selected for the engagement. A walkthrough might compare the documented retention policy to what personnel actually do in ticketing systems, identity platforms, and storage tools. A test of operating effectiveness inspects access reviews, encryption settings, DLP alerts, deletion tickets, privacy-request logs, or breach-response records.

Start every answer with the obligation: HIPAA PHI, GDPR personal data, PCI cardholder data, and confidential customer data each demand different commitments and evidence.

Worked Scenario: Choosing the Right Framework and Control

A simulation describes a US health-technology vendor that processes patient appointment records for clinics and also accepts credit-card payments through its portal. Two obligations apply at once. The patient records make the vendor a business associate subject to HIPAA, so it needs a business associate agreement, the required administrative, physical, and technical safeguards, and breach-notification procedures. The card data places the payment portal inside the PCI DSS cardholder-data environment, so it needs network segmentation isolating the CDE, tokenization of stored card numbers, and quarterly vulnerability scans.

The testable insight: the same company can be governed by different frameworks for different data, and the right control depends on which data and obligation the stem names. If the question asks about protecting stored card numbers, tokenization is the answer; if it asks about disclosing patient data to a clinic, HIPAA permitted uses and the minimum-necessary standard govern.

Privacy Rights and Data-Subject Requests

GDPR and similar regimes grant individuals rights the entity's controls must support: access, rectification, erasure (the right to be forgotten), restriction, portability, and objection. A SOC 2 privacy engagement tests whether the entity can locate all copies of a person's data, honor a deletion request within the required window, and log the request and response. Controls fail here when data is duplicated across backups and vendor systems with no inventory.

Common Traps

1. Calling all personal information "confidential" data and missing that privacy is a separate Trust Services Criteria category with its own commitments.
2. Assuming encryption alone satisfies privacy; encryption protects confidentiality but does not honor consent, notice, retention, or deletion obligations.
3. Picking obfuscation for a production system when production needs real data and access controls instead; masking belongs in development and test.
4. Treating a SOC 3 report as adequate due-diligence evidence when detailed control testing is required.
5. Forgetting that a breach has financial-statement and disclosure consequences, not just IT consequences, for the CPA.