2.3 Notices, Policies, and Oversight of Privacy Operations, Audits, and Third Parties

2.3 Notices, Policies, and Oversight of Privacy Operations, Audits, and Third Parties

Quick Summary: Domain I expects a privacy technologist to implement notices, policies, guidelines, and procedures and to oversee the technical elements of privacy operations, audits, and third-party assessments. In practice that means writing rules engineers can follow, proving that published promises match running systems, and testing vendors rather than trusting their questionnaires.

Legal teams decide what an organization must promise. The privacy technologist makes sure the promise is true in production and that there is evidence to show it. This section covers the document hierarchy that carries privacy requirements inside an organization, the external notices that carry promises to the public, and the technical work behind audits and vendor assessments.

---

The Privacy Document Hierarchy

Internal governance documents form a hierarchy. Mixing up the levels is a common exam distractor.

Technologists usually own or co-own the standards and procedures, because those are where abstract policy becomes engineering work: data classification standards, logging and telemetry standards, retention schedules expressed as time-to-live (TTL) values, secure development requirements, and runbooks for data subject requests and incidents. Good technical standards are testable. "Protect personal data appropriately" cannot be checked; "fields classified as sensitive must be encrypted with a key held in the corporate key management service" can be checked automatically in a pipeline.

Internal Notices and Guidance

Privacy programs also need internal notices: telling employees how their own data is processed (an employee privacy notice), telling engineers which data they may use for testing (no production personal data in lower environments without masking), and telling support staff what they may disclose over the phone. These documents fail when nobody can find them, so link them from the tools people use, such as code review templates, ticket forms, and the data catalog.

---

External Notices: Promises That Must Match the System

An external privacy notice describes what the organization collects, why, with whom it shares data, and how people can exercise their rights. Under GDPR Articles 13 and 14, a notice must include the controller's identity and contact details, the DPO's contact details, the purposes and legal basis for each purpose (including the legitimate interests relied on), recipients or categories of recipients, international transfers and their safeguards, the retention period or the criteria used to set it, the individual's rights, the right to withdraw consent, the right to complain to a supervisory authority, whether providing the data is required, and the existence of automated decision-making. US state laws such as the CCPA add a notice at collection listing categories of personal information, purposes, whether data is sold or shared, and how long each category is kept.

The technologist's job is to keep the notice accurate. Notices drift away from reality when a team adds an analytics SDK, a new data feed, or an AI feature without updating the text. The US Federal Trade Commission (FTC) treats that gap as a deceptive practice under Section 5 of the FTC Act. In 2021, the FTC's order against Flo Health addressed a period-tracking app that had told users their health data would stay private while sharing it with analytics and marketing firms through SDKs. In 2023, GoodRx paid a $1.5 million civil penalty in the first enforcement action under the FTC's Health Breach Notification Rule for sharing health information with advertising platforms contrary to its promises.

Practical controls that keep notices true:

• Map each notice statement to data flows. Each purpose and recipient in the notice should link to entries in the data inventory and record of processing activities.
• Gate releases on notice review. Treat new SDKs, new data categories, and new recipients as triggers for a notice check in the release process.
• Reconcile app store labels. Apple's App Privacy labels and Google Play's Data safety section are public statements; compare them with network traffic captured from test builds.
• Version the notice. Store each version with its effective date so consent records can show which text a person saw.

---

Overseeing Privacy Operations and Audits

Privacy operations are the recurring activities that keep a program working: answering data subject requests, honoring opt-outs and consent changes, running retention and deletion jobs, triaging incidents, and onboarding vendors. The technologist oversees the technical parts and makes them measurable, for example by logging every deletion job with the number of records removed and alerting when a job fails.

Audits test whether controls exist and work. They come from internal audit, external auditors (for example, SOC 2 examinations or ISO/IEC 27701 certification audits), customers auditing a processor, and regulators. The technologist's role is to:

1. Explain the control design in plain terms, with data flow diagrams.
2. Produce evidence, such as configuration exports, access logs, deletion logs, and test results, ideally generated automatically rather than assembled by hand.
3. Support testing, for example by letting an auditor pick a sample of erasure requests and tracing each one through every system.
4. Own remediation of technical findings, with dates and verification.

---

Third-Party Assessments

Most personal data now passes through vendors: cloud platforms, analytics and advertising SDKs, customer support tools, and AI services. A vendor's failure is still the organization's problem, so third-party oversight follows the whole vendor life cycle.

Loading diagram...

Due diligence. Standard questionnaires such as the Shared Assessments SIG or the Cloud Security Alliance CAIQ collect self-reported answers. Treat them as a starting point, not proof.

Reading assurance reports. A SOC 2 Type I report describes whether controls were suitably designed at a point in time; a Type II report tests whether they operated effectively over a period, usually 6 to 12 months. Check the scope (which systems and which Trust Services Criteria, including Privacy), the report period, any exceptions the auditor found, sub-service organizations that were carved out, and the complementary user entity controls (CUECs) your organization must implement for the vendor's controls to work. An ISO/IEC 27001 or 27701 certificate shows a management system was audited; read its scope statement.

Technical validation. Proxy a test build and inspect what an SDK actually sends; confirm that a deletion request removes data from the vendor's systems; check that the vendor's API enforces the access scopes it advertises.

Contract. Under GDPR Article 28, a processor contract must require processing only on documented instructions, confidentiality, appropriate security, conditions for using sub-processors, help with data subject rights and breaches, deletion or return at the end of the service, and support for audits and inspections.

Monitoring and offboarding. Track sub-processor changes, renewals, incidents, and new assurance reports. At the end of the relationship, obtain return or deletion of data and a written certificate of deletion, and revoke credentials and API keys.