Privacy Policy Template: Internal Data Protection Rules Staff Can Follow

Regulators expect an organisation to show how it protects personal data, and an internal data protection policy is usually the first document they ask for. This template is the internal policy, not the public privacy notice: it tells staff, contractors and systems owners what they must do with personal data, who decides, and how compliance is shown. Article 24 of the GDPR (and the UK GDPR) requires controllers to implement appropriate technical and organisational measures and, where proportionate, appropriate data protection policies. The template is written for privacy, security and legal leads who need a policy that maps to those obligations and that engineering and operations teams can actually apply. Adapt it to the laws that bind you and have it approved through your normal governance route.

How to use this template

• Replace text in square brackets, such as [Organisation], [Data Protection Officer], [Privacy Team] and [30 days], with your own names and values. Bracketed values are illustrative unless a law sets them.
• "Must" is mandatory; "should" is recommended practice where a documented deviation is acceptable.
• The template is drafted against the EU GDPR and UK GDPR. If other laws apply (for example US state privacy laws or sector rules), add their requirements in section 4 or an annex. The Global Privacy Regulatory Map helps identify them.
• Keep procedures (DPIA method, request handling steps, breach runbook) in separate documents referenced from this policy, so they can change without re-approval. The DPIA Template covers the assessment itself.
• Legal requirements in this template are summarised. Check the current text of the law and take legal advice before adoption. UK readers should note that the Data (Use and Access) Act 2025 has amended parts of the UK GDPR.

Where each obligation sits

1. Purpose

This policy sets out how [Organisation] protects personal data it collects, uses, stores, shares and deletes, so that processing is lawful, fair and transparent, and so that [Organisation] can demonstrate compliance with [the UK GDPR, the Data Protection Act 2018 and the EU GDPR] and other applicable data protection laws. It forms part of the technical and organisational measures required by Article 24.

2. Scope

• Data: all personal data processed by or for [Organisation], in any format, including employee, customer, supplier and website visitor data, and personal data in logs, backups, test environments and AI training or prompt data.
• People: all employees, contractors, temporary staff and third parties with access to [Organisation]'s personal data or systems.
• Systems: all applications, databases, SaaS services, file shares, devices, analytics and AI tools that hold or process personal data, including automated processes and service accounts that access it.
• Roles: processing where [Organisation] is a controller, joint controller or processor. Where [Organisation] acts as a processor, it processes only on documented instructions from the controller.

3. Roles and responsibilities

4. Policy statements

4.1 Principles and accountability

1. Personal data must be processed in line with the Article 5 principles: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality. [Organisation] must be able to demonstrate compliance (accountability).
2. [Privacy Team] must maintain a record of processing activities (ROPA) covering purposes, categories of individuals and data, recipients, transfers, retention periods and a description of security measures. Asset owners must update it before a new processing activity starts. See the Data Mapping and ROPA Guide.

4.2 Lawful basis and special category data

1. Every processing activity must have a documented lawful basis before it begins. Consent must only be relied on where it is freely given, specific, informed and unambiguous, and can be withdrawn as easily as it was given.
2. Special category data (for example health, biometric, racial or ethnic origin) and criminal offence data must only be processed under an additional documented condition and with [Data Protection Officer] approval.
3. Personal data must not be reused for a new purpose until [Privacy Team] confirms the new purpose is compatible or has its own lawful basis.

4.3 Transparency and individual rights

1. Individuals must be given a privacy notice at the point of collection, or within the time the law allows where data is obtained from others.
2. Any member of staff who receives a request to access, correct, erase, restrict, port or object to processing must forward it to [Privacy Team] within [1 working day]. Requests must be answered without undue delay and within one month, extendable only where the law permits.
3. Decisions based solely on automated processing with legal or similarly significant effects must be identified in the ROPA and reviewed by [Data Protection Officer].

4.4 Privacy by design and DPIAs

1. New systems, changes and suppliers that process personal data must complete the [privacy screening questionnaire] at design stage.
2. A DPIA must be completed before processing that is likely to result in a high risk to individuals, including large-scale special category data, systematic monitoring and new technology such as AI models trained on personal data.
3. Systems must collect only the fields needed, default to the most privacy-protective settings and support deletion at the end of the retention period. See the Privacy by Design Guide for Engineering Teams.

4.5 Security of personal data

1. Personal data must be protected by measures appropriate to the risk, as set in the [Information Security Policy], including encryption in transit and at rest for [Confidential] data, role-based access, logging of access to [high-risk datasets], and tested backups.
2. Access to personal data must be granted on least privilege and reviewed at least [every six months]. Service accounts, API keys and AI agents that read personal data must have a named owner, scoped permissions and appear in the ROPA as part of the processing they perform.
3. Production personal data must not be copied to development, test or analytics environments unless masked, pseudonymised or approved by [Data Protection Officer].
4. Personal data must be retained only as long as set in the [Retention Schedule] and then deleted or anonymised. See the Data Retention and Disposal Policy Template.

4.6 Processors and third parties

1. Processors must only be used where they provide sufficient guarantees, and only under a written contract containing the terms required by Article 28.
2. Processors must be assessed before onboarding and at least [annually] for [high-risk] suppliers, including their use of sub-processors.

4.7 International transfers

1. Personal data must not be transferred outside [the UK / EEA] unless [Privacy Team] has recorded a valid transfer mechanism (for example an adequacy decision or regulations, standard contractual clauses or the UK International Data Transfer Agreement or Addendum) and any required transfer risk assessment.

4.8 Personal data breaches

1. Staff must report any suspected personal data breach to [security incident contact] immediately.
2. [Data Protection Officer] and [CISO] must assess the breach and, where required, notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, and inform affected individuals where the breach is likely to result in a high risk to them.
3. All breaches, including those not notified, must be recorded in the [breach log] with facts, effects and remedial action. See the Breach Notification Laws by Country Guide.

4.9 Training

1. All staff must complete data protection training on joining and [annually]. Staff who handle special category data, rights requests or large datasets must complete [role-based training].

5. Exceptions

Exceptions to sections 4.4 to 4.9 may be approved by [Data Protection Officer] in writing for a defined period of no more than [6 months], with recorded risk and compensating measures. No exception may override a legal requirement.

6. Compliance and monitoring

[Internal Audit] tests compliance at least [annually]. Breaches of this policy may lead to disciplinary action under [HR policy].

7. Review and approval

This policy is reviewed at least [annually], and when the law, regulator guidance or [Organisation]'s processing changes significantly, by [Data Protection Officer], and approved by [Executive Committee]. Version: [1.0]. Effective date: [date]. Next review: [date].

Implementation guidance

1. Map first: build or refresh the ROPA from system owners, the asset inventory and procurement records before publishing the policy, so section 4 is enforceable.
2. Decide the DPO question: record whether a DPO is mandatory (for example public authorities, or core activities involving large-scale monitoring or large-scale special category data) or appointed voluntarily, and give the role the independence the law requires.
3. Pilot procedures: run a test rights request and a tabletop breach exercise against the 72-hour clock before go-live, and fix the gaps they expose.
4. Link to engineering: add the privacy screening questionnaire to architecture review and change management, and add data minimisation and deletion checks to the definition of done.
5. Train and communicate: publish a one-page summary for all staff; give role-based training to HR, marketing, support and engineering.
6. Measure and review: start reporting the metrics above [quarterly]. If a procedure fails in practice, roll back to the previous approved version and record why.

Small and large organisations

• Small: Article 24 asks for policies where proportionate. One policy, a spreadsheet ROPA and a named privacy lead can be enough. The Article 30 record-keeping exemption for organisations with fewer than 250 employees is narrow, so check whether it actually applies before relying on it.
• Large or multinational: add jurisdiction annexes, a privacy champion network, tooling for rights requests and data discovery, and a group-level DPO with local leads.

Common failure patterns

• Policy without a ROPA: statements about lawful basis and retention cannot be tested because nobody knows what is processed where.
• Logs and backups forgotten: personal data in security logs, analytics and backups outlives the retention schedule. See the Privacy in Security Logging Guide.
• Machine access invisible: integrations, service accounts and AI tools read personal data without appearing in the ROPA or access reviews.
• Breach clock misunderstood: teams wait for a full investigation before starting the 72-hour notification assessment.
• Processor terms missing: SaaS tools adopted on a credit card with no data processing agreement.

Framework mapping

Sources: UK GDPR Article 24 (legislation.gov.uk), Regulation (EU) 2016/679 (EUR-Lex), ICO Accountability Framework: policies and procedures.

This template summarises data protection obligations for internal policy purposes and is not legal advice. Related NHI Mgmt Group resources: DPIA Template · GDPR Compliance Guide for Security Teams · UK GDPR and Data Protection Act 2018 Guide · Privacy Programme Guide for Security Teams · Data Classification Policy Template