Data Protection and Privacy Policy

1. Purpose

This policy sets the rules by which the Organisation collects, uses, stores, shares, retains and deletes personal data, and by which it respects the rights of the people the data is about. It is written to support the Digital Personal Data Protection Act, 2023 and its Rules [confirm the current requirement], and to remain usable under applicable law in each jurisdiction where the Organisation operates (such as the EU General Data Protection Regulation).

The policy exists so that the Organisation can:

• process personal data only for clear, lawful and stated purposes, and be able to show the lawful ground for each one;
• give individuals real control over their data: notice, consent where consent is the ground, access, correction, erasure and a working route for complaints;
• protect personal data with safeguards that match the harm a loss would cause, and detect and report breaches inside the periods the law sets;
• make accountability visible: a named owner for every processing activity, a record of what is done and why, and evidence that the rules are followed;
• support the privacy and protection of personal data controls of ISO/IEC 27001:2022 and the contractual promises made to customers.

2. Scope

This policy applies to every employee, contractor, consultant, intern and temporary worker of the Organisation, and to every supplier that handles personal data for the Organisation. It applies wherever personal data is processed: offices, home and remote working, cloud services, customer-facing platforms, internal business systems, paper files, removable media, recordings and backups.

• In scope: personal data of customers, customers' end users, prospects, website and application visitors, employees, candidates, former employees, contractors, suppliers' staff, visitors, and any other identifiable individual.
• In scope: processing in electronic form and in paper form that is later digitised, including collection, recording, structuring, storage, adaptation, retrieval, use, sharing, restriction, erasure and destruction.
• In scope: processing in the Organisation's own right (as Data Fiduciary) and processing on behalf of a customer (as Data Processor).
• Out of scope: fully anonymised data from which no individual can be identified by anyone, using any means reasonably likely to be used. Anonymisation must be approved under this policy before data is treated as out of scope.
• Out of scope: personal data processed by an individual purely for personal or domestic purposes.
• Out of scope: business contact details of a company when no individual can be identified, though most business contact details do identify an individual and so remain in scope.

3. Role Classification

The Organisation plays different roles for different data. The role decides who sets the purpose, who owes notice and consent, and who answers to the regulator. The role for each processing activity must be decided before processing starts and recorded in the record of processing activities.

4. Terms and Definitions

5. Roles and Responsibilities

6. Data Protection and Privacy Policy Statements

The statements below are grouped by topic. Each must be read together with the Data Protection and Privacy Procedure, which gives the steps, forms and time targets, and with the Data Protection Act Compliance Procedure, which maps the obligations of the Digital Personal Data Protection Act, 2023 [confirm the current requirement] to the Organisation's controls.

6.1 Privacy Principles

The Organisation applies the ten principles below to every processing activity. Each principle is tested in the DPIA, the privacy screening of new work and the internal audit.

6.1.1 Accountability and management

• The Board must approve this policy and the Privacy Lead must report to top management [quarterly], covering requests, breaches, DPIAs, audit findings and open risks.
• Every processing activity must have one named data owner who can explain its purpose, ground, recipients and retention.
• The Privacy Lead must have the authority and resources to stop or condition a processing activity that does not meet this policy.
• Privacy objectives must be set each year [for example: close 95 percent of rights requests within the published period] and tracked in the measures.

6.1.2 Fairness and transparency

• Personal data must not be used in ways that would surprise the individual or cause them unjustified harm.
• Dark patterns that push individuals toward giving consent, such as pre-ticked boxes or hidden refusal options, are prohibited.
• Notices and consent requests must be in plain language, in [English and the principal local languages of the audience], and must be easy to find.

6.1.3 Purpose and minimisation

• Each form, API, import and data feed must be reviewed by the data owner against the purpose before release, and every field must have a stated need.
• Data collected for one purpose must not be repurposed for analytics, training of models or marketing without a documented compatibility check by the Privacy Lead.
• Where a purpose can be met with pseudonymised or aggregated data, that form must be used.

6.1.4 Integrity, storage and sharing

• Safeguards must follow the Protection of Personal Data statements below and the Information Security Policy.
• Retention must follow the schedule in the Records and evidence section.
• Sharing and transfers must follow the third party and cross-border statements below.

6.2 Personal Data

Handling rules depend on the kind of data. The Organisation groups personal data into the categories below, and each system, form and dataset must be mapped to the highest category it contains. The Information Classification and Handling Policy sets the labels.

6.2.1 Sensitive personal data

• Sensitive personal data must be collected only where no less intrusive alternative can meet the purpose, and only after the Privacy Lead confirms the lawful ground.
• Sensitive personal data must not be stored in email bodies, chat messages, shared drives without access control, spreadsheets on personal devices or ticket descriptions. Use the approved secure repository.
• Government identifiers must be masked on screen and in exports except for the one role that needs the full value, and a full number must not be used as a search key where a reference number serves.

6.2.2 Children's data

• Before processing the personal data of a child, the data owner must obtain verifiable consent of the parent or lawful guardian and complete a DPIA.
• Tracking, behavioural monitoring and targeted advertising directed at children are prohibited, as the Digital Personal Data Protection Act, 2023 requires of Data Fiduciaries [confirm the current requirement].
• Age must be verified by a method proportionate to the risk, and the method recorded.

6.2.3 Pseudonymised and anonymised data

• Pseudonymised data is personal data and stays under this policy; the key must be held in a different system and role from the data.
• A claim that a dataset is anonymised requires a written re-identification risk test by the Privacy Lead, repeated [yearly] or when new datasets become available that could be combined with it.

6.2.4 Data inventory

• The data inventory must list each system holding personal data, its category, location, owner and connected systems, and be updated within [30 days] of a new system or integration going live.
• Discovery scans for personal data in file shares, mailboxes and cloud storage must run [twice a year], and findings must be owned and resolved within [60 days].

6.3 Collection of Personal Data

The Organisation collects personal data directly from the individual wherever practicable, and in the smallest quantity that serves the purpose.

6.3.1 Collection rules

• Data owners must record the lawful ground and purpose before any collection begins, and the Privacy Lead must approve any new ground.
• Collection forms, scripts, integrations and imports must be reviewed for minimisation: each field marked required, optional or not needed.
• Collection through call recording, cameras, biometric devices, location tracking or browser fingerprinting needs a DPIA first and a visible notice at the point of collection.
• Data collected indirectly, for example from a customer, a partner, a public source or a data broker, must be checked for a lawful route to the Organisation and for accuracy, and the source must be recorded.
• Purchased or rented contact lists must not be used unless the supplier can evidence that the individuals consented to contact by third parties like the Organisation.

6.3.2 Website and application collection

• Cookies and trackers that are not strictly necessary must be off until the visitor opts in, and the choice must be as easy to withdraw as to give.
• Embedded third-party scripts, pixels and software kits must be listed in the data inventory and reviewed by the Privacy Lead before release.
• Analytics must be configured to truncate network addresses and to avoid collecting content typed into forms.

6.3.3 Employee and candidate collection

• Background checks must be limited to what the role requires, consented in writing, and results held only by HR.
• Candidate data of unsuccessful applicants must be erased after [12 months] unless the candidate agrees to be kept on file.

6.4 Consent

Where consent is the lawful ground, the Organisation must be able to prove it, and must stop processing when it is withdrawn.

• A consent request must be separate from other terms, name each purpose, identify the Organisation, state how to withdraw, and give contact details for the grievance contact.
• Silence, inactivity, continued use of a service and pre-ticked boxes are not consent.
• Consent must not be a condition of a service unless the data is necessary for that service.
• The consent record must hold who consented, the notice version shown, the purpose, the channel, the date and time, and the evidence (such as a log entry or signed form), and be kept for [the life of the processing plus 3 years].
• A withdrawal must be actioned in all systems within [7 days] and the individual told. Processing already done before withdrawal remains lawful, and the Privacy Lead decides what data must be erased.
• Where a Consent Manager is used, the Organisation must accept consent and withdrawal given through it and must test the integration [twice a year].
• Consent for existing data collected before the current version of this policy must be refreshed when the purpose changes or [at the next contact], whichever is first.

6.5 Accuracy of Personal Data

• Data owners must define for each dataset how accuracy is maintained: validation at entry, periodic confirmation by the individual and checks for duplicates.
• Data used to make a decision that affects an individual, such as eligibility, pricing, access or employment, must be verified before use and re-verified when older than [12 months].
• A correction request must be actioned within [15 days] across the primary system and all copies, and the recipients of the incorrect data must be told where it has been shared.
• Where data is complete but disputed, it must be flagged as disputed until resolved.
• Staff must not alter personal data to hide a mistake; changes are made through the correction process and logged.

6.6 Notification

Notification means the notice given to individuals at or before collection. It is separate from breach notification, which is covered under Personal Data Breach Management.

• A notice must be given before or at the time of collection, and again when a new purpose or recipient is added.
• The notice must state: the data collected; the purposes; the lawful ground; the recipients or categories of recipients; transfers abroad; the retention period or criteria; how to exercise rights; how to withdraw consent; how to complain to the grievance contact; and how to approach the Data Protection Board if the complaint is not resolved [confirm the current requirement].
• Where the Organisation is a Data Processor, the customer is responsible for giving notice, and the Organisation must give the customer the wording and facts it needs.
• The notice must be available in [English and the other languages the audience uses], and in any language the law requires the Organisation to offer [confirm the current requirement].
• Notices must be versioned. The version shown to each individual must be recorded with the consent or collection record.

6.7 Adequacy of Personal Data

• Data must be adequate for the purpose, relevant to it and not excessive. A dataset that is too thin to serve the purpose fairly must be supplemented through lawful collection, not assumption.
• A quarterly sample of [25] forms and exports per business unit must be reviewed against the purpose and fields found unnecessary must be removed within [30 days].
• When a purpose ends, the data held only for it must be erased or anonymised.

6.8 Protection of Personal Data

Personal data is protected by the controls of the Information Security Policy, applied at the level set by the category of data. The statements below set the privacy-specific minimum. The Organisation must be able to show safeguards that are reasonable for the risk, including encryption, obfuscation or masking, access control, and logs to detect and investigate misuse.

6.8.1 Governance and risk

• Privacy risks must be recorded in the risk register under the Risk Management Policy and treated like any other information risk.
• The Privacy Lead and Head of IT Security must meet [monthly] to review incidents, changes to systems and open actions.
• No new system may hold personal data until the data owner has completed the privacy screening and the Head of IT Security has confirmed the safeguards.

6.8.2 Access control

• Access to personal data is granted on least privilege and need to know under the Access Control Policy, with the owner approving each grant and an access review [every 6 months] for sensitive personal data and [every 12 months] for other personal data.
• Administrators and support staff must not browse customer or employee data except to resolve a ticket, and access outside a ticket must be justified in the log.
• Shared accounts must not be used to access personal data. Multi-factor authentication is required for all remote access and all administrative access to systems holding personal data.
• Access must be removed on the day an individual leaves or changes role, in line with the HR Security Policy.

6.8.3 Encryption, masking and pseudonymisation

• Personal data must be encrypted in transit using [TLS 1.2 or higher] and at rest using [AES-256 or equivalent], with keys managed under the Cryptography Policy.
• Sensitive personal data must be masked or tokenised in lower environments, reports, logs and support tools, and shown in full only where the role needs it.
• Pseudonymisation must be applied to analytics, testing and model training wherever the work can be done without direct identifiers.

6.8.4 Storage, copies and removable media

• Personal data must be stored only in approved repositories. Copies on laptops, phones, personal storage, messaging applications and personal email are prohibited.
• Removable media may hold personal data only if it is encrypted, issued by IT and logged, and must be wiped on return.
• Production personal data must not be used in development or test. Where unavoidable, the data owner and Privacy Lead must approve masked copies, and the copy must be deleted within [30 days].
• Backups of personal data must be encrypted, access-controlled and expire at the end of the backup retention period; the Backup and Restoration Policy applies.

6.8.5 Physical and paper records

• Paper records containing personal data must be stored in locked cabinets, with access limited to named roles, and must be shredded or securely destroyed on expiry.
• A clear-desk and clear-screen rule applies to areas where personal data is in use. Printing of sensitive personal data is prohibited unless the data owner approves.
• Visitor registers must be designed to avoid one visitor seeing the details of another.

6.8.6 Remote and mobile working

• Staff working remotely must use the managed device or approved virtual desktop, a protected network, and must not work on personal data in public places where screens or calls can be seen or overheard.
• Mobile devices holding personal data must be enrolled in mobile device management with remote wipe, a screen lock and device encryption; the Mobile Device and Teleworking Policy applies.

6.8.7 Logging and detection

• Access to sensitive personal data, bulk exports and changes to permissions must be logged and reviewed at least [weekly] by IT security.
• Alerts must be set for bulk downloads, access to unusual volumes of records, access outside the normal hours of a user, and attempts to send personal data to unapproved destinations.
• Logs of ICT systems must be kept for [180 days] and, as the CERT-In Directions of 28 April 2022 require, within Indian jurisdiction [confirm the current requirement]. Logs must not themselves hold unnecessary personal data.

6.8.8 Data loss prevention

• Email, web upload and endpoint controls must detect the leaving of structured personal data (identifier patterns, large lists, bulk exports) and block or quarantine it unless approved.
• Screen capture and printing of sensitive personal data from support tools should be disabled for roles that do not need them.

6.8.9 Retention and deletion

• Each dataset must have a retention period in the schedule, and deletion must be automated where the system allows.
• On expiry, the data owner must erase the data from live systems within [30 days] and from backups on rotation within [the backup cycle], or anonymise it with Privacy Lead approval.
• Where a law, contract or legal hold requires retention, the data must be restricted to that purpose and the holder named in the RoPA.
• Deletion must be evidenced by a log or certificate, and storage media must be sanitised under the Asset Disposal Process.

6.8.10 Rights of Data Principals

The days above are the Organisation's internal targets and must not exceed any period set by the Digital Personal Data Protection Act, 2023 and its Rules [confirm the current requirement]. The Privacy Lead confirms the periods each year.

• The identity of a requester must be verified proportionately before data is released, without collecting more data than needed.
• A request is logged in the request register on receipt, whichever channel it arrives by, and staff who receive one must forward it to the grievance contact within [1 working day].
• A request may be refused or limited only for a lawful reason recorded by the Privacy Lead, with the reason and the route of complaint explained to the requester.
• Requests received by the Organisation as a Data Processor must be passed to the customer within [2 working days] and not answered directly unless the contract says so.

6.9 Communications Privacy

The Organisation uses email, chat, telephony, video meetings, messaging and customer-facing platforms that carry personal data. Messages and recordings are treated as personal data of everyone in them.

6.9.1 Business communications

• Business email, chat and meeting tools are provided for work. The Organisation may access communications stored in them only for security, legal, audit, investigation or operational reasons set out in the Acceptable Usage Policy.
• Access to an individual's mailbox or chat history requires a written request from HR, Legal or the Head of IT Security, approval by the Privacy Lead, and a record of what was accessed, by whom and why.
• Sensitive personal data must not be sent in clear text over email, chat or messaging. Use an approved secure transfer method.
• Auto-forwarding of business mail to personal accounts is prohibited. Distribution lists that include personal data must be reviewed [every 6 months].

6.9.2 Calls and recordings

• Calls, meetings and screens may be recorded only for a stated purpose such as training, quality, dispute resolution or legal compliance, with a notice given at the start of each call.
• Recordings are personal data. They must be stored encrypted, access-limited, and deleted after [90 days] unless needed for a dispute or complaint.
• Participants may object to recording, and the Organisation must offer an alternative route where practicable.

6.9.3 Marketing and customer communications

• Direct marketing by email, phone, text message or messaging application needs consent or another recorded lawful ground, and must follow communications and anti-spam rules applicable in the country concerned.
• Every marketing message must name the sender and carry a working opt-out. Opt-outs must be actioned within [7 days] and held on a suppression list that survives list cleansing and imports.
• Transactional or service messages must not be used to carry promotion unless the recipient has consented.
• Customer-facing platforms operated for a customer must send messages only on the customer's instruction, and the Organisation must not use content, recipients or traffic data for its own purposes.

6.9.4 Employee monitoring

• Monitoring of staff, devices, networks, building access and camera footage must be proportionate, notified in the employee privacy notice, and limited to security, safety, legal compliance and service quality.
• Continuous or covert monitoring of an individual is prohibited unless Legal and the Privacy Lead approve it in writing for a specific investigation, for a defined period.
• Monitoring results must be used only for the stated purpose. Personal communications must not be read, and automated filtering is preferred over human reading.

6.10 Acceptable Use of Personal Data

• Personnel must use personal data only for the purpose it was collected for, only for their duties, and only through approved tools, as the Acceptable Usage Policy sets out.
• Personnel must not search for, view or share the data of friends, family, colleagues, celebrities or other individuals without a work reason; such access is treated as a breach of this policy.
• Personnel must not publish or discuss personal data on social media, in public forums, in generative AI tools that are not approved, or in unapproved messaging groups.

6.11 Privacy Monitoring and Review

• The Privacy Lead must run a monitoring programme made up of the activities in the frequency schedule below, and report results to top management.
• Findings must be entered in the corrective action register with an owner and a date. High findings must close within [30 days], medium within [90 days].
• Privacy metrics (see Measures) must be reviewed in the management review under the ISMS.

6.12 Privacy Reporting

• Each quarter the Privacy Lead must report to top management on: rights requests received and closed in time; complaints and outcomes; breaches and near misses; DPIAs completed and open; third parties reviewed; audit findings; training completion; and regulatory changes.
• Material events, such as a notifiable breach, a complaint to the Data Protection Board or a regulator enquiry, must be reported to top management within [24 hours] of the Privacy Lead learning of them.
• Customers whose data the Organisation processes must be given the reports their contract requires, including breach reports and the sub-processor list.

6.13 Privacy by Design and Default

• Every new product, feature, process, integration, analytics use or procurement that touches personal data must pass a privacy screening before design is approved, using the screening questions in Annexure B.
• Defaults must be the most protective: collection off unless needed, sharing off, retention short, visibility limited to the individual, and marketing opt-in.
• Requirements for rights handling (export, correction, deletion, consent withdrawal) must be built into systems from the start, not added afterwards.
• Developers must use test data that is synthetic or masked, and must follow the secure development practices in the Systems Acquisition, Development and Maintenance Policy.
• Changes that alter the purpose, data, recipients, location or retention of an existing system must be treated as new work for screening purposes.

6.14 Privacy Notice

The Organisation publishes a privacy notice for each audience: website visitors and customers, customers' end users where the Organisation is the Data Fiduciary, employees and candidates, and suppliers. Each notice must hold the content below.

• A notice change that affects purposes, recipients or retention must be approved by the Privacy Lead and Legal before publication, and existing individuals must be told through an appropriate channel.
• Each version of a notice must be archived with its dates in use.

6.15 Dissemination of Privacy Program Information

• This policy, in summary form, and the privacy notice must be published on the intranet and website, and every new joiner must read and acknowledge them in their first [5 working days].
• All personnel must complete privacy training on joining and [every 12 months] after, with a short assessment pass mark of [80 percent]. Roles that handle sensitive personal data, rights requests or marketing data must take role-based training.
• The Privacy Lead must run short awareness messages [quarterly] drawn from real near misses, and appoint privacy champions in business units with a heavy flow of personal data.
• Training completion must be reported to top management. Staff who do not complete training within [30 days] of the due date have their access to systems holding sensitive personal data suspended until they do.

6.16 Sharing with Third Parties

Sharing means disclosure to, access by or hosting with any party outside the Organisation. It is allowed only where the sharing is covered by a lawful ground, consistent with the notice, necessary for the purpose and supported by a written agreement.

6.16.1 Data processing agreement terms

A data processing agreement must be signed before a third party receives personal data. The terms in the table below are the minimum; Annexure C of the Data Governance Policy gives sample wording.

• Processing only on documented instructions, for the stated purpose, and no use for the third party's own purposes.
• A duty of confidentiality on everyone who handles the data and a list of safeguards at least as strong as the Organisation's own.
• Written approval before any sub-processor is engaged, and the same terms flowed down to it.
• Notification of a breach without undue delay and within [24 hours], with the facts the Organisation needs to meet its own duties.
• Assistance with rights requests, impact assessments and regulator enquiries within [5 working days].
• Audit rights, evidence on request and annual assurance reporting for high-risk suppliers.
• Return or deletion of data at the end of the contract within [30 days], with a certificate of deletion.
• No transfer outside the agreed countries without written approval.

6.16.2 Due diligence and ongoing control

• The Privacy Lead and Head of IT Security must assess each third party that will handle personal data before contract. High-risk suppliers, those handling sensitive personal data or large volumes, are reviewed [every 12 months]; others [every 24 months].
• Third parties must be recorded in the supplier register with the data they hold, the contract end date and the owner. The Supplier Relationship Management Policy applies.
• If a third party has a breach, loses its assurance evidence or breaches the agreement, the data owner must decide within [10 working days] whether to suspend sharing and recover or delete the data.

6.16.3 Cross-border transfers

• Personal data may be transferred or made accessible outside India only where the Digital Personal Data Protection Act, 2023 and any restrictions notified under it permit [confirm the current requirement], and where the law of any other country concerned is met.
• Each transfer must have a completed transfer assessment (see the Data Governance Policy, Annexure D), a contract with equivalent protection, and a record in the RoPA.
• Remote access from abroad to systems holding personal data, for support or administration, is a transfer and must be approved in the same way.
• Where a customer contract limits storage to a country or region, the contract term overrides convenience, and engineering must prove the limit by technical controls.

6.17 Personal Data Breach Management

A personal data breach is an information security incident that affects personal data. It is handled under the Information Security Incident Management Policy and Incident Management Procedure, with the privacy-specific steps below added.

6.17.1 Detection and reporting

• Every person must report a suspected or actual breach to the service desk or the security mailbox immediately, and in any case within [1 hour] of noticing. Reports may be made without fear of blame for honest mistakes.
• The service desk must open an incident marked 'personal data' and alert the Head of IT Security and the Privacy Lead within [30 minutes] of receiving the report.
• Suppliers must report to the Organisation's named contact within [24 hours], or sooner if the contract says so.

6.17.2 Assessment

The Privacy Lead and Head of IT Security must assess each breach within [24 hours] of it being reported, using the table below, and record the decision and its reasons.

6.17.3 Notification

• Where the Organisation is the Data Fiduciary, the Privacy Lead must notify the Data Protection Board and each affected Data Principal of a personal data breach in the form and within the time the Digital Personal Data Protection Act, 2023 and its Rules prescribe [confirm the current requirement].
• Where the Organisation is the Data Processor, it must notify the customer within [24 hours] of confirming a breach, and cooperate in the customer's notifications.
• Where the breach is also a cyber incident of a type notifiable under the CERT-In Directions of 28 April 2022, it must be reported to CERT-In within 6 hours of the Organisation noticing it [confirm the current requirement].
• The notice to individuals must state what happened, what data was involved, what the Organisation has done, what the individual can do to protect themselves, and who to contact.
• Regulators in other jurisdictions must be notified where applicable law in those jurisdictions requires it, and Legal decides the clock for each.

6.17.4 Containment, recovery and learning

• Containment actions such as revoking credentials, isolating systems, recalling messages and requesting deletion from recipients must be started immediately and logged.
• A post-incident review must be held within [10 working days] of closure of every medium or higher breach, with root cause, control gaps and actions entered into the corrective action register.
• Evidence must be preserved under the evidence-handling rules of the Information Security Incident Management Policy.

6.18 Data Breach Response Team

The Breach Response Team is formed when a breach is assessed as high or critical, and may be convened earlier at the Privacy Lead's discretion. It meets in person or online within [2 hours] of being convened.

• A deputy for each member must be named, and contact details must be tested [every 6 months].
• The team must keep a decision log, with times, decisions, who made them and why. The log is part of the breach record.
• The team must run a tabletop exercise [every 12 months] using a realistic scenario, and record lessons learned.

6.19 Internal Audit Review Mechanism

• Privacy controls must be included in the internal audit programme at least [once every 12 months] and cover a sample of processing activities, systems and suppliers on a risk basis.
• Auditors must test whether: the RoPA matches reality; notices match the practice; consent records are complete; requests were closed in time; retention is applied; access lists are correct; DPIAs were done where required; and suppliers meet the agreement.
• Audit reports must go to top management and the Privacy Lead, findings must be rated, and the Privacy Lead must report progress against actions [monthly] until closed.
• Where the Organisation is a Significant Data Fiduciary, an independent data audit by a qualified auditor must be carried out and the report kept as the law requires [confirm the current requirement].
• The Internal Audit and Management Review Procedure sets the method.

6.20 Data Protection Impact Assessment

A DPIA is required before processing that is likely to result in high risk to individuals. The data owner completes it with the Privacy Lead, using the form in Annexure B.

6.20.1 DPIA content

• Description of the processing: purpose, data, people, scale, systems, recipients, locations and retention.
• Necessity and proportionality: why this data and this method, and what alternatives were considered.
• Risks to individuals: loss of confidentiality, unfair outcome, loss of control, discrimination, financial harm, physical harm; each rated for likelihood and severity.
• Measures to reduce each risk, residual risk, owner and date.
• Consultation: the views of affected groups where practicable, and of the Head of IT Security and Legal.
• Decision: proceed, proceed with conditions, redesign or stop, signed by the data owner and the Privacy Lead.

6.20.2 DPIA process rules

• A DPIA must be completed before go-live and within [20 working days] of the screening decision. Work must not go live while a high residual risk is open unless top management accepts it in writing.
• DPIAs must be reviewed [every 12 months] and when the processing changes.
• Where the Organisation is a Significant Data Fiduciary, periodic impact assessment must follow the format and frequency prescribed [confirm the current requirement].

6.21 Records of Processing Activities

The Privacy Lead keeps the RoPA as a controlled record. It is the primary document for demonstrating compliance and for answering customers and regulators.

• The RoPA must be updated within [30 days] of any change to the processing and confirmed by the data owner [every 6 months].
• The RoPA must be consistent with the data inventory, the notice and the supplier register, and the Privacy Lead must test the match [yearly].
• The RoPA must be available to customers and regulators on request, in the form the Privacy Lead approves.

7. Compliance and Monitoring

Adherence to this policy is checked by the following routes. Results are reported to top management in the privacy report and in the management review.

• The Privacy Lead reviews the metrics in the Measures table [monthly] and the evidence in the Records and evidence table [quarterly].
• Data owners attest [every 6 months] that their RoPA entries, notices and access lists are correct.
• Internal audit tests privacy controls as set out under Internal Audit Review Mechanism.
• The Head of IT Security reviews logs, data loss alerts and cookie scans as set out in the Privacy Monitoring and Review schedule.
• Customers and external auditors may test the Organisation's controls under the audit rights in contracts.

8. Records and Evidence

The records below are evidence of compliance. They are controlled under the Documents and Records Management Procedure.

Annexure A: Record of processing activities template

Annexure B: Privacy screening and DPIA form

Annexure C: Rights request and complaint register

Annexure D: Personal data breach register

9. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

10. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

11. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Data Protection and Privacy Procedure
• Data Protection Act Compliance Procedure
• Information Security Incident Management Policy
• Data Governance Policy
• Information Classification and Handling Policy
• Supplier Relationship Management Policy