What is the difference between a privacy notice and a data privacy policy under the MCDPA?

A privacy notice explains to consumers what personal data is processed, why it is processed, how rights can be exercised, and how to appeal decisions. A data privacy policy is an internal description of the organisation’s compliance approach, including governance ownership, system design considerations, security practices, data inventory, minimisation, retention, and remediation procedures. One is outward facing, the other operational.

How the Two Documents Differ in Purpose

A privacy notice and a data privacy policy serve different audiences and different control objectives. The notice is the consumer-facing disclosure, so it explains what personal data is collected, why it is used, and how a person can exercise rights. The policy is the organisation’s internal operating rulebook, so it translates privacy obligations into governance, design, security, inventory, retention, and remediation practices.

That distinction matters because the notice is judged by transparency and user understanding, while the policy is judged by whether the organisation can actually run a compliant privacy programme. A good notice can still sit on top of a weak internal policy, but a weak policy usually produces inconsistent notices, poor records, and gaps in accountability.

For organisations building a privacy programme, the policy should be the source of truth. It should define ownership, review cadence, escalation paths, and how the organisation decides what must be disclosed externally. The notice should then be derived from that operational stance, not written as a marketing summary detached from the underlying practices.

What Belongs in the Notice Versus the Policy

The notice should stay outward-facing and practical. It should tell consumers what categories of personal data are processed, the legal or business purpose for processing, how long data is generally kept, how rights requests are handled, and how to appeal or challenge a decision where the MCDPA requires that path.

The policy should go deeper and stay internal. It should describe the governance model, how data inventories are maintained, how minimisation is enforced, how retention rules are set and reviewed, what security practices protect the data, and what remediation steps apply when something goes wrong. This is where organisations document the mechanics that allow the external notice to be accurate.

That internal detail becomes especially important for systems that depend on machine-to-machine access, shared credentials, or API-driven processing. If the organisation cannot explain where personal data flows and who can reach it, the notice may be technically correct but operationally ungrounded. NHIMG’s Ultimate Guide to NHIs is useful here because it connects governance to the identity and access conditions that often sit behind data handling.

What Practitioners Should Watch For Under the MCDPA

Under a law like the MCDPA, the biggest failure mode is treating the notice as a legal document and the policy as an afterthought. If those two artefacts are not aligned, the organisation can end up promising one thing externally while operating another thing internally. That creates disclosure risk, process drift, and avoidable compliance findings.

Another common issue is overloading the privacy notice with internal process language. Consumers need clarity, not a policy digest. At the same time, the internal policy cannot be vague, because vague policy language leaves too much to individual teams and makes retention, minimisation, and security controls hard to verify.

For teams handling credentialed systems, broad access paths, or service-side processing, it is worth remembering that internal privacy controls depend on operational discipline around data location and access. NHIMG’s IOS app secrets leakage report is a concrete example of how weak secret handling can undermine privacy outcomes even when the user-facing story looks sound. The NIST Privacy Framework is also a strong external reference for structuring governance, data mapping, and privacy risk management.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the technical controls, while EU AI Act define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST AI RMF	GOVERN — Govern	Governs privacy risk management, accountability, and oversight for the internal policy.
	MAP — Map	Supports data inventory, context, and processing purpose mapping inside the policy.
	MANAGE — Manage	Covers operational controls, minimisation, retention, and remediation practices described in the policy.
Recommendation — Establish privacy governance, ownership, and review accountability for the policy. Map personal data flows, purposes, and lifecycle handling before drafting disclosures. Implement controls for minimisation, retention, and remediation that match the notice.
NIST CSF 2.0	GV.RM-03 — Risk management strategy is established and communicated	The policy needs an internal governance strategy that consistently drives privacy handling.
Recommendation — Document the privacy risk strategy and align internal handling rules to it.
CIS Controls v8	5 — Account Management	Identity and access governance affects who can process personal data and how it is controlled.
	3 — Data Protection	Covers retention, minimisation, and protection of personal data referenced by the policy.
Recommendation — Restrict personal-data access to approved accounts and review it regularly. Apply data-protection safeguards to limit collection, storage, and exposure.
NIST SP 800-63	IAL — Identity Assurance Level	Appears where the notice or process requires reliable identity proofing for rights requests.
Recommendation — Verify requester identity proportionately before disclosing or changing personal data.
EU AI Act	Transparency obligations	Relevant only if the notice covers automated or AI-assisted decision-making disclosures.
Recommendation — Disclose automated decision-making and provide meaningful user-facing explanations where required.

Practitioner Guidance

What to verify: Confirm that every statement in the notice can be traced back to an internal policy, procedure, or system control. If the notice says rights can be exercised or data is retained for a defined period, the organisation should be able to show the workflow and evidence that supports it.

What to prioritise: Make the policy the operational control document first, then derive the notice from it. That sequence reduces the risk of disclosure drift and forces ownership, inventory, minimisation, and remediation decisions to be made before external language is published.

Practitioner takeaway: The notice tells people what you do, but the policy proves you can do it consistently; if the two diverge, the compliance problem is usually operational rather than linguistic.