What is a data classification policy template?

A data classification policy template is the published rule a security or governance function maintains for how the organisation labels, handles, stores, transmits, retains, and destroys data based on the sensitivity of the information and the harm an unauthorised disclosure would cause. Data here means every information asset the organisation holds: customer personal information, payment card data, protected health data, employee data, financial records, source code, design documents, internal communications, security artefacts, vendor data, contractual records, board minutes, audit working papers, training materials, marketing materials, and operational telemetry. The policy publishes a tier set (typically four tiers such as public, internal, confidential, restricted) with named example data classes per tier, the handling requirements per tier across storage, transmission, processing, sharing, retention, and destruction, the labelling discipline the organisation runs against, and the named owner per tier of data. It sits one level below the wider information security policy and one level above the operational artefacts (the DLP rule set, the labelling guidance, the data retention schedule, the secure disposal procedure, the data sharing agreement library). It is the document the auditor reads when checking ISO/IEC 27001 Annex A 5.12 (classification of information) and A 5.13 (labelling of information), ISO/IEC 27002 controls 5.12 and 5.13, NIST SP 800-60 (mapping types of information to security categories), NIST SP 800-53 RA-2 (security categorisation) and SC-28 (protection of information at rest), GDPR Article 32 (security of processing) and Article 5 (data minimisation), HIPAA Security Rule 45 CFR 164.312, PCI DSS 4.x Requirements 3 and 9.4, SOC 2 Common Criteria CC6.1 and CC6.7, FedRAMP FIPS 199 categorisation, NIS2 Article 21, DORA Articles 8 and 9, and the CISA Cybersecurity Performance Goals (CPGs) baseline expectations against your real practice. The template below names the durable shape of that policy so the firm publishes a rule the audit reads against rather than running on tribal knowledge that breaks the moment a new system is onboarded or a regulator asks how a data class is handled.

How is a data classification policy different from a data handling standard or a data retention schedule?

A data classification policy publishes the tier set, the named example data classes per tier, and the handling rules at the tier level. A data handling standard is the technical companion that names the approved encryption algorithms, the approved storage systems, the approved transmission channels, the approved sharing channels, and the approved disposal methods per tier (a data classification policy can require AES-256 encryption at rest for confidential data; the data handling standard names that AES-256-GCM is the approved mode and that key management runs against the Cryptographic Key Management Policy). A data retention schedule is the per-data-class table of how long each class is retained, the trigger that starts the retention clock, the destruction discipline at the end of retention, and the legal hold path that pauses retention for litigation, regulatory investigation, or contractual dispute. The three artefacts read together: the classification policy says what tier a record belongs to, the handling standard says what protection mechanisms apply at that tier, and the retention schedule says how long the record lives. Mature programmes publish the classification policy as the parent and reference the handling standard and the retention schedule from Section 12 (compliance crosswalk). Smaller programmes publish one combined policy that contains all three; the template below is structured so the handling and retention sections can be split out if the programme later separates them.

What frameworks expect a data classification policy?

Every modern security and privacy framework expects either an explicit data classification policy or the practices that one codifies. ISO/IEC 27001:2022 Annex A 5.12 (classification of information) and A 5.13 (labelling of information) expect documented classification procedures evidenced through policy. ISO/IEC 27002:2022 controls 5.12 and 5.13 publish the implementation guidance for those Annex A controls. NIST SP 800-60 (Guide for Mapping Types of Information and Information Systems to Security Categories) is the canonical federal reference for how information is categorised. NIST SP 800-53 RA-2 (security categorisation), SC-28 (protection of information at rest), and MP-3 (media marking) expect documented categorisation evidenced through policy. FIPS 199 publishes the federal categorisation thresholds (low, moderate, high) that NIST SP 800-60 maps against and that FedRAMP authorisations read against. GDPR Article 32 (security of processing) expects appropriate technical and organisational measures proportionate to the sensitivity of the data; Article 5 (data minimisation) expects that data processing is adequate, relevant, and limited to what is necessary. HIPAA Security Rule 45 CFR 164.312 expects technical safeguards proportionate to the sensitivity of protected health information. PCI DSS 4.x Requirement 3 (protect stored account data) and 9.4 (control media storage and accessibility) read directly against the classification of cardholder data. SOC 2 Common Criteria CC6.1 (logical and physical access controls) and CC6.7 (data classification and handling) expect documented data classification controls. NIS2 Article 21 covers information classification as part of the cybersecurity risk management framework in the EU. DORA Articles 8 and 9 cover the classification and protection of ICT assets including information assets. The CISA Cybersecurity Performance Goals (CPGs) include data classification as a baseline expectation. Map each framework reference into Section 12 (compliance crosswalk) when you customise the template so the policy reads against the actual control set your audit cycle uses.

How many classification tiers should the policy publish?

Four tiers is the operationally defensible balance between expressiveness and usability. Two tiers (public and confidential) is too coarse: every protected record collapses into one tier with no rule for graded handling between an internal-only Slack channel and a customer payment record. Six or seven tiers is too granular: the labelling discipline breaks because no one can remember which tier a quarterly business review deck belongs in. The four-tier set most commonly published is Public (the organisation has chosen to make this data available; no harm from disclosure; examples include marketing pages, published blog posts, public regulatory filings, public job postings), Internal (data that supports day-to-day operations but is not intended for public disclosure; harm from disclosure is limited and largely reputational; examples include internal procedures, internal organisation charts, training materials, non-sensitive internal communications), Confidential (data whose disclosure would cause material harm to the organisation, its customers, its employees, or its counterparties; examples include customer personal information, employee personal information, financial records, contract terms, board materials, security findings, vulnerability reports, source code, design documents, vendor agreements), and Restricted (data whose disclosure would cause severe harm and that is subject to specific legal, regulatory, or contractual obligations; examples include payment card data under PCI DSS, protected health data under HIPAA, biometric data under regional privacy law, government-controlled information under FedRAMP or CMMC, board executive session minutes, mergers and acquisitions material, customer-controlled BYOK material, security incident response artefacts during an active incident). The template below uses this four-tier set as the published example; tune the tier labels (some programmes prefer Public, Internal Use Only, Confidential, Highly Confidential, or numeric Tier 1 through Tier 4) to match the rest of the security programme. Whatever tier set you publish, the same tier set must run across the data inventory, the labelling discipline, the handling standard, the retention schedule, the DLP rule set, the access control review, the audit evidence pack, the customer assurance review, and the regulator inspection.

How does the policy connect to a data inventory and a record of processing?

A data classification policy is unenforceable without a data inventory. The inventory records every information asset the organisation holds with the data class, the classification tier under this policy, the named owner (the business function that produces and maintains the asset), the named custodian (the technical function that operates the storage system), the storage location, the processing systems, the access roles, the legal basis for processing where the data is personal information, the retention class against the data retention schedule, the third-party processor list where the data leaves the organisation, the cross-border transfer arrangement where the data leaves the jurisdiction, the regulatory regime (GDPR, HIPAA, PCI DSS, FedRAMP, CMMC, NIS2, DORA) the data falls under, and the linked engagement record where applicable. For data classes containing personal information the inventory typically extends into a Record of Processing (Article 30 of the GDPR; equivalent records under UK GDPR, Brazilian LGPD, Australian Privacy Act 1988, and most modern privacy regimes) that names the purpose of processing, the legal basis, the categories of data subjects, the categories of recipients, the international transfer arrangements, the retention period, and a description of the technical and organisational security measures. The classification policy and the data inventory operate together: the policy publishes the tier set and the handling rule per tier, and the inventory publishes which records belong in which tier with the named owner and custodian per asset. The data flow diagram visualises the path data takes between systems with the tier label preserved at each hop. The classification policy enforces that the inventory is current (the policy publishes the cadence of inventory review and the trigger for ad-hoc inventory updates) and that the inventory reads cleanly against the audit when a regulator or customer asks for the evidence pack.

How should the policy handle labelling, metadata, and DLP enforcement?

Labelling is the operational mechanism that makes classification enforceable. The policy publishes the labelling discipline per data system: documents use the platform-native sensitivity label (Microsoft Information Protection labels, Google Workspace labels, Adobe sensitivity attributes) that travels with the document across forwarding, copying, and download; structured data in databases uses table or column metadata that DLP rules and access control read against; source code repositories use repository visibility (public, internal, private) plus metadata files in the repository root that name the classification of the data the repository processes; chat platforms use channel-level classification plus message-level data loss prevention rules for confidential and restricted content; email uses platform-native sensitivity labels that the email gateway enforces against unauthorised forwarding or unauthorised attachment. Where the platform does not support native labelling, the policy publishes the alternative discipline (a published list of repositories and channels with the classification, a metadata file convention, a colour-coded folder structure with documented mappings, or a tagging convention in a ticket system) so the audit can read which assets sit at which tier even without platform-native labels. Data loss prevention (DLP) tooling enforces the policy at the network edge, at the endpoint, and at the cloud storage boundary by reading the label or the content-classification rule set the DLP system has been trained against. Findings from DLP enforcement (an attempted exfiltration of confidential data, a sharing event to an unauthorised counterparty, a misrouted email with a confidential attachment) flow into the security findings workspace where the triage, the remediation, the access review, and the lessons-learned read against the same record the rest of the security programme runs on. The classification policy publishes the relationship to the DLP rule set, the named owner of the DLP rule set, and the cadence of DLP rule tuning so a reviewer can read which classification tier triggers which DLP enforcement action.

How does the policy connect to SecPortal?

SecPortal carries the operational record the policy runs against. Findings management holds the per-detection state (open, in progress, accepted risk, closed, verified closed) with severity, owner, due date, and remediation evidence for findings that touch classified data: sensitive-data exposure findings from authenticated DAST against pages handling regulated data, exposed-cloud-storage and credential-leak findings from external scanning across 16 modules, hardcoded-credential and unsafe-data-handling findings from Semgrep code scanning against connected repositories, manually logged DSPM and CSPM exports through bulk finding import, DLP alert escalations logged manually, third-party pentest findings consolidated on the same record, and bug bounty submissions all land on the same queue (see findings management). Code scanning runs Semgrep against connected GitHub, GitLab, and Bitbucket repositories with rules that detect unsafe data handling (hardcoded PII patterns, weak cryptography on personal data, insecure deserialisation, SQL injection that touches sensitive tables, logging of sensitive values) and lands each detection on an engagement record with the file path, line number, rule reference, and confidence indicator (see code scanning). Authenticated scanning runs DAST against pages behind the login screen that touch regulated data, with encrypted credential storage protecting the test credentials at rest with AES-256-GCM (see authenticated scanning and encrypted credential storage). External scanning across 16 modules covers exposed cloud storage, leaked credentials, subdomain enumeration, certificate transparency mining, TLS configuration, and security headers on the verified perimeter that touches regulated data (see external scanning). Finding overrides hold the suppression decisions for documented test fixtures with rationale and an expiry on accepted-risk decisions (see finding overrides). Document management retains the classification policy file, the data inventory baseline, the DPIA artefact for high-risk processing, the data retention schedule, the regulator correspondence, the third-party processor list, and the revision history alongside the operational record (see document management). Activity log carries the timestamped chain of state changes by user so the elapsed time between detection, triage, remediation, verification, and closure is observable rather than asserted (see activity log). Team management with RBAC gates the severity override path, the exception approval ladder, the policy publishing authority, and the role-scoped read on classified-data findings (see team management). Continuous monitoring schedules the recurring scans so changes to systems touching classified data are detected on the published cadence rather than the next manual run (see continuous monitoring). AI report generation produces the privacy steering committee, the data governance committee, and the audit committee summary on the same engagement data (see AI reports). Compliance tracking maps findings touching classified data and the surrounding controls to ISO 27001, ISO 27018, ISO 27701, SOC 2, PCI DSS, HIPAA, GDPR, and NIST framework expectations with CSV export (see compliance tracking). SecPortal does NOT classify data, does NOT operate a data discovery engine that scans datastores for sensitive content patterns, does NOT operate a DLP enforcement plane, does NOT run a privacy-platform consent management workflow, does NOT issue data subject access request fulfilment letters, does NOT integrate with the data catalogue or the metadata management system, does NOT integrate with Jira, ServiceNow, Slack, SIEM, or SOAR, and does NOT host or process the classified data itself. The data classification, the data inventory, the labelling discipline, and the DLP enforcement live in the systems the data sits in; SecPortal carries the operational evidence and the finding lifecycle that the classification policy runs against.

What does the policy say about data owners, custodians, and stewards?

Data ownership is the contested part of the policy at audit and at incident response. The policy publishes the role definitions so the named owner per data class is unambiguous. The data owner is the business function that produces, uses, and approves the lifecycle of a data class; the owner authorises classification at the tier the policy permits for the data type, authorises access at the role level, authorises exceptions where the handling rule cannot be met, and is accountable for the residual risk on data the owner approves. The data custodian is the technical function that operates the storage system, the processing system, and the access mechanism; the custodian implements the technical controls the handling standard requires, operates the backup and recovery, runs the access reviews, runs the deletion at end of retention, and is accountable for the technical implementation of the rule the owner approves. The data steward is the operational function that maintains the data quality, the metadata, and the inventory record for a data class; the steward maintains the data definitions, the data dictionary, the data lineage, the master data, and is accountable for the inventory accuracy and the cross-system consistency. For personal information specifically the policy names the Data Protection Officer (DPO) or equivalent privacy officer as the regulatory contact, the named owner of the Record of Processing, and the named decision-maker on the DPIA outcomes. The role matrix is published in Section 3 of the template and is referenced from Section 12 (compliance crosswalk) where the audit reads the named role against the framework expectation (the GDPR controller and processor roles, the HIPAA Security Officer and Privacy Officer roles, the PCI DSS Information Security Officer role, the ISO 27001 risk owner role). Programmes that publish the policy without the role matrix find that incident response stalls at the question of who authorises the access reset, the retention extension, the breach notification timeline, and the residual risk acceptance; an audit reads the gap immediately.

How often should the data classification policy be reviewed?

The defensible cadence is annual minimum review with material-change-triggered revision. Annual review tests whether the tier set still matches the threat environment and the regulatory horizon (a new privacy regulation in scope, a new sectoral regulation, a new customer contract requiring stricter classification rules, a new processing activity that did not exist at the prior review), whether the named example data classes per tier still match the live estate (a new product line that produces a new data class, a new data subject category, a new transfer mechanism that did not exist before), whether the handling requirements per tier still match the technical estate (a new storage platform, a new transmission channel, a new sharing platform, a new disposal mechanism), whether the framework crosswalk in Section 12 still reflects the current control catalogue (PCI DSS major version transition, ISO 27001:2022 revision cycle, NIST CSF 2.0 alignment, NIS2 transposition status, DORA effective date, FedRAMP authorisation cycle), whether the role matrix in Section 3 still names the right roles for the operating model, and whether the labelling discipline in Section 5 still reflects the available platform capabilities. Material change triggers an off-cycle revision: a new regulation in scope (a US state privacy law, an EU-level data act, a sectoral regulation), an acquisition that brings in a new data estate with inherited classification rules, a divestiture that removes a data estate, a significant incident that surfaces a question the policy should have answered, a customer audit that requires the firm to demonstrate stricter classification discipline, a regulator inspection that highlights a gap, a privacy programme adoption (new DPIA process, new consent platform, new data subject rights workflow), a major technology change (new cloud provider, new data platform, new collaboration suite, new sharing platform), or a public emergence of a threat the policy should classify differently against. The revision is logged in the document control history with the date, summary, approver, and rationale; the prior version is retained per the audit evidence retention policy. The policy is signed at publication and at every material revision; staff with access to confidential or restricted data acknowledge the policy on hire and at every material revision, with the acknowledgement evidence retained per the audit evidence retention policy.

How does the policy handle cross-border data transfers and third-party processors?

The policy publishes the rule for data leaving the organisational boundary and the rule for data leaving the jurisdiction. For third-party processors (the cloud platforms the data sits on, the SaaS vendors that process the data, the contractors that touch the data, the support providers that access the data) the policy requires a documented data processing agreement (DPA) before any confidential or restricted data is shared, with the legal basis for processing, the categories of data, the categories of data subjects where personal information is involved, the security measures the processor commits to, the breach notification timeline, the subprocessor flow-down requirement, and the audit right per the contractual term. The vendor security risk assessment runs against the processor before onboarding and at the documented review cadence; findings flow into the security findings workspace. For cross-border transfers the policy publishes the approved transfer mechanisms per jurisdiction pair (GDPR adequacy decisions, the EU-US Data Privacy Framework, Standard Contractual Clauses, Binding Corporate Rules, derogations under GDPR Article 49, equivalent mechanisms under UK GDPR, the EU-Japan adequacy decision, the EU-UK adequacy decision, the equivalent decisions under regional regimes), the supplementary measures (encryption at the boundary, key control by the data exporter, pseudonymisation) where the transfer mechanism alone is insufficient, and the documented Transfer Impact Assessment for restricted-tier data crossing into a jurisdiction without adequacy. The policy publishes the prohibition on confidential or restricted data leaving the boundary outside a documented agreement and a documented transfer mechanism. Programmes that omit this section find that the auditor reads transfers as undocumented, the customer assurance review reads transfers as unmanaged, and the regulator reads transfers as a breach of the cross-border transfer rules. The third-party processor list is maintained in the data inventory and reviewed at the annual cadence and on every onboarding or offboarding.

Free Tool

Data Classification Policy Template
twelve sections for tier definitions, inventory discipline, labelling, handling per tier, third-party transfers, retention, DPIA, and a defensible sign-off

A free, copy-ready data classification and handling policy template for internal security, AppSec, product security, cloud security, platform engineering, vulnerability management, data security, GRC, and privacy teams that need to publish a defensible rule for how the organisation labels, handles, stores, transmits, retains, and destroys data based on the sensitivity of the information and the harm an unauthorised disclosure would cause. Twelve structured sections covering policy charter and authority, scope and information assets in scope, roles responsibilities and the approval ladder, classification tiers and example data classes, labelling and metadata and inventory discipline, handling rules per tier across storage transmission processing sharing access and disposal, sharing third-party processors and cross-border transfers, retention legal hold and destruction, DPIA breach notification and exception register, logging monitoring and audit evidence, review revision and acknowledgement, and framework crosswalk plus signatures. Aligned with ISO/IEC 27001:2022 Annex A 5.12 and 5.13, ISO/IEC 27002:2022, ISO/IEC 27018, ISO/IEC 27701, NIST SP 800-53 RA-2 and SC-28 and MP-3, NIST SP 800-60, NIST SP 800-88, FIPS 199, GDPR Articles 5, 25, 30, 32, 33, 35 and 49, HIPAA Security Rule 45 CFR 164.312, PCI DSS 4.x Requirement 3, SOC 2 CC6.1 and CC6.7, NIS2 Article 21, DORA Articles 8 and 9, and the CISA Cybersecurity Performance Goals.

Get Started Free

No credit card required. Free plan available forever.

Twelve sections that turn data classification into a defensible policy

A data classification policy is the rule a security or governance function publishes to declare how the organisation labels, handles, stores, transmits, retains, and destroys data based on the sensitivity of the information and the harm an unauthorised disclosure would cause. The discipline matters because data exposure incidents (a leaked customer export, a misconfigured cloud storage bucket, a tier 4 spreadsheet emailed to the wrong recipient, a tier 3 source file pushed to a public repository, an unmanaged third-party processor handling regulated data, a cross-border transfer without the required mechanism, a retention overflow on personal information past the lawful basis) are a recurring incident category, a recurring audit finding category, and a recurring regulatory finding category across ISO/IEC 27001 Annex A 5.12 and 5.13, ISO/IEC 27018, ISO/IEC 27701, NIST SP 800-53 RA-2 and SC-28, NIST SP 800-60, FIPS 199, GDPR Articles 5 and 25 and 30 and 32, HIPAA Security Rule 45 CFR 164.312, PCI DSS Requirement 3, SOC 2 CC6.1 and CC6.7, NIS2 Article 21, DORA Articles 8 and 9, and the CISA Cybersecurity Performance Goals. The twelve sections below cover the durable shape of the artefact. Copy the section that fits your stage and paste the rest as you go.

The policy is not a substitute for the operational artefacts the programme runs against. Pair it with the cryptographic key management policy template for the cryptographic material that backs the encryption requirements named in this policy, the secrets management policy template for the operational credentials that authenticate access to classified data, the vulnerability management policy template for the umbrella programme rule the finding lifecycle touching classified data plugs into, the vulnerability remediation SLA policy template for the SLA windows that govern triage and closure timing on classified-data findings, the security exception register template for the aggregate ledger of accepted risk on handling rules that cannot be met, the risk acceptance form template for the per-decision artefact behind every exception, the audit evidence retention policy template for the retention rule that governs classification decisions, DPIA artefacts, and destruction evidence, and the vulnerability management RACI matrix template for the operating-model artefact that names the Accountable role per lifecycle step referenced from Section 3.

Copy the full policy (all twelve sections) as one block.

1. Policy charter and authority

Open the policy with the firm intent and the executive authority. A reviewer reading the first paragraph should know who publishes the rule, which estate it covers, which executive signed it, and when it went into effect. ISO/IEC 27001 Clause 5.2 expects documented information security policies with named authority; the data classification policy sits one level below the umbrella ISMS policy and one level above the operational artefacts (the labelling guidance, the data handling standard, the data retention schedule, the DLP rule set, the secure disposal procedure). The charter answers the first audit question (what programme exists, who signed it) before the policy moves into operational rules.

Policy title: Data Classification and Handling Policy
Policy version: {{POLICY_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Last review date: {{LAST_REVIEW_DATE}}
Next review date: {{NEXT_REVIEW_DATE}}

Policy purpose:
{{PLAIN_LANGUAGE_PURPOSE_PARAGRAPH}}

Policy objectives (the rule the audit reads against):
- Classify every information asset the organisation produces, holds, processes, transmits, shares, or retains into a published tier so the handling discipline scales with the sensitivity of the data.
- Maintain a current data inventory that names the asset, the data class, the classification tier, the named owner, the named custodian, the storage location, the retention class, the regulatory regime, and the linked engagement record where applicable.
- Apply the published handling rules per tier across storage, transmission, processing, sharing, retention, and destruction so a reviewer can read the rule against the live estate at any moment.
- Label data using the platform-native sensitivity label where the platform supports it, or the published alternative discipline (metadata convention, repository visibility tier, channel-level classification, folder structure mapping) where the platform does not, so labelling discipline is enforceable rather than aspirational.
- Enforce data loss prevention (DLP) controls aligned to the classification tier at the network edge, the endpoint, the cloud storage boundary, and the collaboration suite.
- Run a documented data protection impact assessment (DPIA) for any new processing activity that touches restricted or high-volume confidential personal information.
- Maintain a Record of Processing for personal information per GDPR Article 30 and equivalent records under other regional privacy regimes.
- Apply the published cross-border transfer rules for restricted and confidential data leaving the jurisdiction.
- Maintain an audit-readable evidence chain for classification decisions, handling exceptions, retention executions, destruction events, and material policy revisions.

Programme sponsor (executive authority that publishes the policy):
- Name: {{EXECUTIVE_SPONSOR_NAME}}
- Role: {{EXECUTIVE_SPONSOR_ROLE}}

Approving authority: {{APPROVING_AUTHORITY_NAME_AND_ROLE}}
Approval date: {{APPROVAL_DATE}}

Policy hierarchy:
- Parent policy: Information Security Policy / Information Security Management System.
- Sibling policies referenced by this policy:
  - Data Handling Standard (the technical companion that names approved storage systems, encryption algorithms, transmission channels, sharing platforms, and disposal methods per tier).
  - Data Retention Schedule (the per-class table of retention period, trigger, destruction method, and legal hold path).
  - Privacy Policy (the published rule for personal information handling and the data subject rights workflow).
  - Acceptable Use Policy (the published rule for employee handling of classified data on company systems and personal devices).
  - Cryptographic Key Management Policy (the published rule for cryptographic material that backs the encryption requirements named in this policy).
  - Secrets Management Policy (the published rule for operational credentials that authenticate access to classified data).
  - Vulnerability Management Policy (the published umbrella rule for the finding lifecycle that touches classified data).
  - Security Exception Register Policy (the published residual-risk path for handling rules that cannot be met).
  - Risk Acceptance Policy (the per-decision artefact behind every exception).
  - Audit Evidence Retention Policy (the retention rule that governs classification decisions, DPIA artefacts, and destruction evidence).
  - Vendor and Third-Party Security Policy (the published rule for third-party access to classified data and the data processing agreement requirement).
  - Incident Response Policy (the published rule for breach notification timelines and classification of incidents touching classified data).

Frameworks the policy evidences (map your scope into Section 12):
- ISO/IEC 27001:2022 Annex A 5.12 (classification of information), A 5.13 (labelling of information), A 5.14 (information transfer), A 5.34 (privacy and protection of PII), A 8.10 (information deletion), A 8.11 (data masking), A 8.12 (data leakage prevention).
- ISO/IEC 27002:2022 implementation guidance for the above controls.
- ISO/IEC 27018:2019 (personal data on public cloud).
- ISO/IEC 27701:2019 (privacy information management extension to 27001).
- NIST SP 800-53 RA-2 (security categorisation), SC-28 (protection of information at rest), MP-3 (media marking), MP-4 (media storage), MP-6 (media sanitisation).
- NIST SP 800-60 Volume 1 and Volume 2 (mapping types of information to security categories).
- NIST SP 800-88 (media sanitisation).
- FIPS 199 (security categorisation of federal information).
- GDPR Article 5 (data minimisation), Article 25 (data protection by design and by default), Article 30 (records of processing), Article 32 (security of processing), Article 35 (data protection impact assessment).
- HIPAA Security Rule 45 CFR 164.312 (technical safeguards), 164.314 (organisational requirements).
- PCI DSS 4.x Requirement 3 (protect stored account data), 9.4 (control media), 12.10 (incident response).
- SOC 2 Common Criteria CC6.1 (logical and physical access controls), CC6.7 (data classification and handling), CC7.2 (system monitoring).
- NIS2 Article 21 (cybersecurity risk management measures).
- DORA Articles 8 (identification) and 9 (protection and prevention).
- CISA Cybersecurity Performance Goals (CPGs).
- Internal policy: {{INTERNAL_POLICY_REFERENCES}}

2. Scope and information assets in scope

Scope is the contested part of the policy at audit. Name what counts as an information asset, where the policy applies, who is bound by it, and what is explicitly out of scope. Without an explicit boundary the policy is unenforceable because every grey-zone asset becomes a case-by-case interpretation rather than a published rule.

In-scope information assets (carry the full policy):
- Customer data: customer profile records, customer contact details, customer billing data, customer payment instruments, customer support transcripts, customer-generated content held on company systems.
- Personal information: data identifying or reasonably capable of identifying a natural person, including employee, contractor, candidate, vendor contact, and partner contact records.
- Special-category personal information: health information, biometric identifiers, government-issued identifiers, financial account numbers, sexual orientation, racial or ethnic origin, religious or philosophical beliefs, trade union membership, genetic data, criminal records.
- Payment card data: primary account numbers (PAN), sensitive authentication data (SAD), cardholder names, expiration dates, service codes, where the organisation handles card data under PCI DSS scope.
- Protected health information (PHI) as defined under HIPAA and equivalent regional regimes.
- Financial records: ledger entries, journal entries, financial statements, tax records, audit working papers, board financial materials.
- Source code and software artefacts: production source code, infrastructure-as-code, configuration-as-code, build artefacts, container images, deployment manifests, automated test fixtures (where they contain real data), pipeline scripts.
- Design documents: product specifications, architecture diagrams, threat models, security designs, decision records.
- Operational telemetry: production logs, access logs, audit logs, security event logs, application logs, infrastructure metrics.
- Security artefacts: vulnerability reports, pentest findings, scanner output, incident response artefacts, threat intelligence, security control evidence, DPIA outputs, security risk assessments.
- Vendor and contractual records: signed contracts, master service agreements, data processing agreements, vendor risk assessments, vendor security questionnaires, vendor onboarding evidence.
- Board and executive materials: board minutes, board meeting decks, executive committee minutes, board committee charters, strategic plans.
- Internal communications: email, chat, video meeting recordings, document collaboration trails, internal social platforms, intranet content.
- Customer assurance evidence: customer-facing trust centre materials, customer security questionnaire responses, customer-specific compliance evidence packs.
- Regulatory correspondence: filings, regulatory queries and responses, examination correspondence, attestation packages.
- {{ADDITIONAL_IN_SCOPE_INFORMATION_ASSETS}}

Out-of-scope or modified-scope items:
- Personal cryptographic keys, personal passwords, and personal credentials engineers use for personal accounts outside company systems.
- Personal devices that have not been enrolled in the company mobile device management programme and on which company data is not permitted.
- Data held by a third party under a published data processing agreement where the third party is the data controller and the firm is not the processor (the policy still governs how that party interacts with the firm).
- Publicly available data that the firm did not produce and that contains no personal information about identified or identifiable individuals.
- {{ADDITIONAL_OUT_OF_SCOPE_BOUNDARIES}}

Locations and systems in scope:
- Production systems and the data they hold.
- Non-production systems (development, staging, test, sandbox, QA) where they hold any production or production-derived data.
- Backup systems, archive systems, and exported support bundles.
- Endpoint devices (laptops, desktops, mobile devices) issued to or enrolled by the organisation.
- Cloud storage (object stores, block storage, file storage, database storage) holding in-scope data.
- Collaboration platforms (document collaboration, chat, email, video meeting, ticket tracker, wiki, intranet) holding in-scope data.
- Source code repositories (production code repositories, infrastructure repositories, documentation repositories).
- CI/CD pipelines and build artefact stores.
- Container image registries and image manifests.
- Third-party SaaS platforms holding in-scope data under documented data processing agreements.
- {{ADDITIONAL_IN_SCOPE_LOCATIONS}}

People bound by the policy:
- All employees of the organisation worldwide.
- All contractors, consultants, and temporary workers with access to in-scope data.
- All third parties accessing in-scope data under a documented data processing agreement, to the extent the contractual term flows the requirements through.
- All visitors granted ad-hoc access to in-scope systems holding classified data.

Geographic scope: {{GEOGRAPHIC_SCOPE}}
Regulatory regimes in scope: {{REGULATORY_REGIMES_IN_SCOPE}} (typical entries include GDPR, UK GDPR, CCPA / CPRA, HIPAA, PCI DSS, FedRAMP, CMMC, NIS2, DORA, ISO 27001, SOC 2, regional privacy regimes the firm operates under).

3. Roles, responsibilities, and the approval ladder

Name the roles so the policy is enforceable rather than aspirational. Without a named owner per data class, classification decisions stall at the question of who authorises the tier. Without a named approver per exception band, exceptions accumulate without a defensible decision trail. The role matrix is the artefact the audit reads against framework expectations (the GDPR controller and processor roles, the HIPAA Security Officer and Privacy Officer roles, the PCI DSS Information Security Officer role, the ISO 27001 risk owner role).

Policy owner: {{POLICY_OWNER_ROLE}}
- Maintains the policy text, schedules the annual review, drives material revisions.
- Sole authority to publish a new version after approval.

Operational owner (programme function that operates the policy day to day): {{OPERATIONAL_OWNER_ROLE}}
- Operates the data classification programme.
- Owns the labelling discipline, the DLP rule set governance, the data inventory cadence, and the operational metrics.
- Reports programme performance into the wider information security programme review cycle.

Data Protection Officer (DPO) or equivalent privacy officer: {{DATA_PROTECTION_OFFICER}}
- Regulatory contact for personal information.
- Named owner of the Record of Processing.
- Named decision-maker on DPIA outcomes.
- Authority to halt processing where unmitigated high risk to data subjects is identified.

Data owners (business function that produces and approves the lifecycle of a data class):
- Customer data owner: {{CUSTOMER_DATA_OWNER}}.
- Employee data owner: {{EMPLOYEE_DATA_OWNER}}.
- Financial data owner: {{FINANCIAL_DATA_OWNER}}.
- Source code and product data owner: {{SOURCE_CODE_OWNER}}.
- Vendor and contractual data owner: {{VENDOR_DATA_OWNER}}.
- Board and executive material owner: {{BOARD_DATA_OWNER}}.
- Security artefact owner: {{SECURITY_ARTEFACT_OWNER}}.
- {{ADDITIONAL_DATA_OWNERS}}

Data custodians (technical function that operates the storage system, processing system, and access mechanism):
- Cloud platform custodian: {{CLOUD_PLATFORM_CUSTODIAN}}.
- Endpoint custodian: {{ENDPOINT_CUSTODIAN}}.
- Collaboration platform custodian: {{COLLABORATION_CUSTODIAN}}.
- Source code platform custodian: {{SOURCE_CODE_CUSTODIAN}}.
- Identity platform custodian: {{IDENTITY_CUSTODIAN}}.
- {{ADDITIONAL_DATA_CUSTODIANS}}

Data stewards (operational function that maintains the data quality, metadata, and inventory record):
- Customer data steward: {{CUSTOMER_DATA_STEWARD}}.
- Employee data steward: {{EMPLOYEE_DATA_STEWARD}}.
- Master data steward: {{MASTER_DATA_STEWARD}}.
- {{ADDITIONAL_DATA_STEWARDS}}

Per-lifecycle-step responsibility:
- Classify at creation: the data owner classifies new data classes; the data steward records the classification in the inventory.
- Label: the originating system applies the platform-native label or the published alternative discipline.
- Store: the custodian operates the storage in alignment with the handling rule per tier.
- Transmit and share: the originating user or system follows the published transmission and sharing rule per tier.
- Reclassify: the data owner authorises tier changes (typically downgrades require senior security and privacy sign-off; upgrades require owner authorisation and may trigger DPIA).
- Run DPIA: the operational owner schedules the DPIA; the DPO signs off; the data owner approves residual risk.
- Approve exceptions: tiered approval ladder per residual rating (see Section 9).
- Execute retention: the custodian operates the deletion at end of retention; the steward records the execution evidence.
- Respond to incidents: the incident response function operates the breach notification workflow; the DPO authorises personal information regulator notification timelines; the data owner authorises customer notification.

Approval ladder for severity overrides and exception decisions:
- Tier downgrade on a data class: data owner with security review.
- Tier upgrade on a data class: data owner; may trigger DPIA if the upgrade reflects newly identified risk.
- Exception filing for a handling rule that cannot be met at residual rating low or medium: operational owner.
- Exception at residual rating high: head of security with compensating control documented.
- Exception at residual rating critical: head of security and DPO and executive sponsor with compensating control documented and a hard expiry that does not exceed 90 days without renewed approval.
- Extension of retention beyond the published schedule: data owner with legal review where the extension is driven by litigation or regulatory hold.
- Cross-border transfer of restricted-tier data into a jurisdiction without an adequacy decision: DPO and head of security with transfer impact assessment recorded.
- Policy revision: policy owner, operational owner, DPO sign-off, head of security sign-off, audit committee notification.

RACI summary (referenced from the operating model documentation):
- Responsible per step: see the lifecycle responsibility list above.
- Accountable end to end: head of security or CISO; DPO accountable for personal information specifically.
- Consulted: privacy counsel, internal audit for evidence design, GRC for framework crosswalk, finance for financial data retention rules, HR for employee data rules, customer success for customer data rules, engineering leadership for source code and infrastructure data rules.
- Informed: business unit heads with material data dependencies, audit committee at quarterly cadence, customers whose data is subject to material policy changes through trust centre or customer notification, regulators where notification obligations apply.

4. Classification tiers and example data classes

Publish the tier set with named example data classes per tier so a reader does not have to interpret which tier a record belongs to. Tier labels can be tuned to match the rest of the security programme (Public / Internal / Confidential / Restricted is the published example; some programmes prefer Public / Internal Use Only / Confidential / Highly Confidential, or numeric Tier 1 through Tier 4). Whatever the labels, the same tier set must run across the inventory, the labelling, the handling standard, the retention schedule, the DLP rule set, the access control review, and the audit evidence pack.

Tier 1 - Public:
Definition: data the organisation has chosen to make available; no harm from unauthorised disclosure.
Example data classes:
- Published marketing pages, blog posts, press releases, public regulatory filings.
- Published privacy policy, terms of service, cookie notice.
- Published job postings and recruiting materials.
- Published security trust centre materials and public security certifications.
- Published open-source code repositories where the firm is the publisher.
- Published API documentation for public-tier APIs.
- {{ADDITIONAL_TIER_1_EXAMPLES}}

Tier 2 - Internal:
Definition: data that supports day-to-day operations and is not intended for public disclosure; limited and largely reputational harm from unauthorised disclosure.
Example data classes:
- Internal procedures, runbooks, standard operating procedures.
- Internal organisation charts, role guides, internal training materials.
- Non-sensitive internal communications (internal newsletters, all-hands recordings without confidential content, intranet content).
- Internal product roadmap discussion documents at non-sensitive granularity.
- Aggregate operational telemetry that does not identify individuals or expose security details.
- Non-sensitive internal wiki content.
- {{ADDITIONAL_TIER_2_EXAMPLES}}

Tier 3 - Confidential:
Definition: data whose unauthorised disclosure would cause material harm to the organisation, its customers, its employees, or its counterparties.
Example data classes:
- Customer personal information that is not special category (customer profile, customer contact details, customer billing data, customer support transcripts).
- Employee personal information (HR records, payroll records, performance reviews, employment contracts).
- Vendor and contractual records (contracts, master service agreements, vendor risk assessments).
- Source code (production source code, infrastructure-as-code, configuration-as-code, build artefacts).
- Design documents (product specifications, architecture diagrams, security designs).
- Security artefacts (vulnerability reports, pentest findings, scanner output, incident response artefacts).
- Financial records that are not material non-public information.
- Internal product roadmap at sensitive granularity.
- Operational logs that contain customer or employee identifiers.
- Non-sensitive board materials (committee minutes for non-executive sessions).
- {{ADDITIONAL_TIER_3_EXAMPLES}}

Tier 4 - Restricted:
Definition: data whose unauthorised disclosure would cause severe harm and that is subject to specific legal, regulatory, or contractual obligations.
Example data classes:
- Payment card data subject to PCI DSS scope (primary account numbers, sensitive authentication data, cardholder names paired with PAN).
- Protected health information subject to HIPAA scope.
- Special-category personal information under GDPR Article 9 (health, biometric, genetic, racial, ethnic, religious, philosophical, sexual orientation, trade union membership) and equivalent regional regimes.
- Government-issued identifiers (national identifiers, passport numbers, driver licence numbers) paired with other personal information.
- Financial account numbers paired with credentials or other authentication factors.
- Customer-controlled BYOK material and customer-pinned cryptographic keys.
- Material non-public financial information.
- Board executive session minutes and mergers and acquisitions materials.
- Security incident response artefacts during an active incident.
- Government-controlled information under FedRAMP or CMMC scope.
- Litigation hold material and legal privilege material.
- {{ADDITIONAL_TIER_4_EXAMPLES}}

Reclassification rules:
- A record's tier may rise without security or privacy sign-off (the owner identifies that the record warrants stricter handling).
- A record's tier may not be lowered without sign-off from the data owner, the head of security, and (for personal information) the DPO.
- Tier downgrades require documented justification (the data has aged into a less sensitive state, the contractual restriction has ended, the regulatory regime has changed, the record has been redacted or aggregated to a less sensitive form).
- Aggregation or pseudonymisation that reduces re-identification risk may justify downgrade only after a documented re-identification risk assessment.

Inheritance rules:
- A composite record inherits the highest tier of any data class it contains (a spreadsheet that combines internal data with one column of confidential customer data is classified at the confidential tier).
- A derived record (a report, an export, a dashboard, a log entry, a backup) inherits the tier of the source data class.
- A workflow that processes data in transit between systems applies the tier of the highest-tier data class in the workflow.
- A backup or archive of a tier holds the same tier as the live data; encryption and access control match the tier.

5. Labelling, metadata, and inventory discipline

Labelling is the operational mechanism that makes classification enforceable. Publish the labelling discipline per data system so the audit can read which assets sit at which tier. Where the platform supports native sensitivity labels, the labels are the published mechanism. Where the platform does not, the policy publishes the alternative discipline (metadata convention, repository visibility tier, channel-level classification, folder structure mapping) so labelling is not aspirational.

Labelling discipline per platform:
- Document collaboration suite (Microsoft 365, Google Workspace): platform-native sensitivity labels (Microsoft Information Protection labels, Google Workspace labels) on every document, spreadsheet, presentation, and form that contains tier 3 or tier 4 data. Default labels apply at folder, drive, or workspace level.
- Email: platform-native sensitivity labels on outbound email containing tier 3 or tier 4 content; gateway-enforced label-aware DLP rules block unauthorised external forwarding and unauthorised attachments.
- Chat (Slack, Microsoft Teams): channel-level classification recorded in the channel topic or channel description; per-message DLP rules detect tier 4 patterns in tier 1, tier 2, or tier 3 channels and alert.
- Video meetings: recordings inherit the tier of the highest-tier topic discussed; tier 4 meetings are not recorded by default; transcription is disabled where the discussion touches tier 4 content unless a specific business need is approved.
- Source code repositories: repository visibility (public, internal, private, organisation-internal) plus a metadata file in the repository root (.classification.yaml or equivalent) that names the tier of the data the repository processes and the regulatory regimes the data is subject to.
- Container image registries: image tags follow the published convention; image metadata records the tier of the data the image processes.
- Database storage: table-level or column-level metadata tags read by the access control system and the DLP rule set; data dictionary entries record the tier per column.
- Cloud storage (object stores, file stores, block stores): bucket or container metadata records the tier; lifecycle policies enforce the retention schedule per tier; encryption at rest applies the algorithm and key from the Data Handling Standard.
- Ticket trackers (Jira, ServiceNow, GitHub Issues): tier-classified ticket fields where supported; tier 4 content is not stored in ticket comments outside the documented exception path.
- Wikis and intranets: page-level classification recorded in the page header or page metadata; permissions enforce read access aligned to tier.

Data inventory requirements:
- The inventory records every information asset the organisation holds with:
- Asset identifier.
- Data class.
- Classification tier under this policy.
- Named owner (the business function).
- Named custodian (the technical function).
- Named steward (the operational function for data quality and metadata).
- Storage location (system, region, environment).
- Processing systems (the systems that read, write, transform, derive).
- Access roles (the roles authorised at each tier).
- Legal basis for processing where the data is personal information.
- Retention class against the data retention schedule.
- Regulatory regime (GDPR, HIPAA, PCI DSS, FedRAMP, CMMC, NIS2, DORA, regional privacy regimes) the data falls under.
- Third-party processor list where the data leaves the organisation.
- Cross-border transfer arrangement where the data leaves the jurisdiction.
- Linked engagement record where applicable.
- The inventory is reviewed at least quarterly for tier 4 entries, semi-annually for tier 3, annually for tier 2 and tier 1.
- Ad-hoc inventory updates are triggered by: new system onboarding, new data class introduction, regulatory regime change, contractual change with a third-party processor, ownership change, classification reclassification, incident affecting the asset.

Record of Processing (for personal information):
- A Record of Processing per GDPR Article 30 and equivalent records under UK GDPR, CCPA / CPRA, regional privacy regimes is maintained for every processing activity that touches personal information.
- The record names the purpose of processing, the legal basis, the categories of data subjects, the categories of personal information, the categories of recipients, the third-country transfers and the safeguards, the retention period, and a description of the technical and organisational security measures.
- The record is reviewed at the inventory cadence and on every material processing change.

Data flow diagrams:
- Tier 3 and tier 4 processing activities have a maintained data flow diagram that shows the systems the data touches, the transmission channels between them, the third-party processors involved, the cross-border boundaries, the encryption boundaries, and the retention endpoints.
- The diagram is referenced from the DPIA where the processing activity warrants one.
- The diagram is reviewed at least annually and on every material processing change.

6. Handling rules per tier

This section is the operational heart of the policy. Publish the handling rule per tier across storage, transmission, processing, sharing, access, and disposal so the rule is citable rather than implied. Where the rule references a technical specification, the Data Handling Standard names the algorithm, the channel, or the system; this section names the discipline at the tier level.

Tier 1 - Public:
- Storage: any approved storage system. No encryption requirement beyond platform defaults.
- Transmission: any channel. Integrity-protected transmission (HTTPS, signed payloads) for content the firm publishes.
- Processing: no special processing constraint.
- Sharing: published to the public.
- Access: open access.
- Disposal: per platform lifecycle defaults; deletion of public content is at the publisher's discretion subject to any archive obligation.

Tier 2 - Internal:
- Storage: company-managed systems with authenticated access; encryption at rest per platform defaults.
- Transmission: TLS in transit for all transmission outside the company network; internal transmission per platform defaults; collaboration suite native channels.
- Processing: by company employees, contractors, and approved third parties operating under a documented data processing agreement.
- Sharing: with company personnel; with approved counterparties under a confidentiality agreement; not published externally.
- Access: authenticated access; broad access within the company is acceptable unless a more specific access rule applies.
- Disposal: per the Data Retention Schedule for the data class.

Tier 3 - Confidential:
- Storage: company-managed systems with authenticated access and encryption at rest using approved cryptography per the Cryptographic Key Management Policy and the Data Handling Standard; backups encrypted at rest.
- Transmission: TLS 1.2 or later in transit for all transmission; for tier 3 personal information leaving the jurisdiction, the published cross-border transfer mechanism applies; for tier 3 data shared with a third party outside the firm boundary, a documented data processing agreement is in place.
- Processing: by company personnel with a business need, scoped to least privilege; third-party processing requires a data processing agreement and a vendor security risk assessment.
- Sharing: with company personnel on a need-to-know basis; with third parties only under a documented data processing agreement or signed confidentiality agreement that flows the handling requirements through.
- Access: role-based access control per the Identity and Access Management Policy; multi-factor authentication enforced; quarterly access reviews; activity logged.
- Disposal: per the Data Retention Schedule; secure deletion using methods approved in the Data Handling Standard; physical media sanitised per NIST SP 800-88 where physical media is in use; destruction evidence retained per the Audit Evidence Retention Policy.
- Labelling: platform-native sensitivity label where supported; published alternative discipline where not.
- DLP enforcement: tier 3 patterns trigger DLP rules at the endpoint, the network edge, and the cloud storage boundary; egress to personal email or personal cloud storage is blocked or alerted per the rule set.

Tier 4 - Restricted:
- Storage: company-managed systems with authenticated access and encryption at rest using approved cryptography per the Cryptographic Key Management Policy and the Data Handling Standard; tier 4 cryptographic keys held in an HSM or FIPS-validated cloud KMS per the cryptographic key tier requirement; backups encrypted at rest and air-gapped or immutable where the framework scope requires.
- Transmission: TLS 1.2 or later in transit for all transmission with the cipher suite the Data Handling Standard names; for tier 4 personal information leaving the jurisdiction, the published cross-border transfer mechanism applies and a Transfer Impact Assessment is documented; tier 4 data is not transmitted over chat platforms or unsecured email; for tier 4 data shared with a third party, a data processing agreement that explicitly addresses the tier 4 obligations is in place.
- Processing: by named personnel with a documented business need, scoped to least privilege per record where the platform supports it; third-party processing requires a data processing agreement, a vendor security risk assessment, and (for personal information) a documented DPIA.
- Sharing: with named personnel on a per-decision basis; with third parties only under a documented data processing agreement that names the tier 4 controls; sharing with regulators, auditors, and counsel under the established disclosure protocol.
- Access: role-based access control with named-individual approval; multi-factor authentication with phishing-resistant factors where the framework scope requires; monthly access reviews; activity logged and alerted; tier 4 access additions documented on the engagement record.
- Disposal: per the Data Retention Schedule; secure deletion with destruction evidence retained per the Audit Evidence Retention Policy; physical media sanitised per NIST SP 800-88 with destruction attestation; tier 4 destruction requires the destruction method, the named operator, the destruction timestamp, and the witness signature where the regulatory regime requires.
- Labelling: platform-native sensitivity label is mandatory; tier 4 content without a label is treated as a finding; the label travels with the document across forwarding, copying, and download.
- DLP enforcement: tier 4 patterns trigger blocking DLP rules at the endpoint, the network edge, the cloud storage boundary, the collaboration suite, and the email gateway; egress to personal email, personal cloud storage, or unsecured chat platforms is blocked; attempts are alerted to the security operations function and logged on the security finding record.
- Logging: access to tier 4 data is logged with the user identity, the access timestamp, the access purpose where the platform supports it, and the action; logs are retained per the Audit Evidence Retention Policy.
- Print and physical handling: tier 4 data is not printed outside the documented exception path; printed tier 4 material is shredded using a cross-cut shredder rated for confidential paper; shredding is logged where the regulatory regime requires.

Common controls across tiers 3 and 4:
- Encryption in transit on every transmission channel that crosses a trust boundary.
- Encryption at rest in every storage system where the data is persisted.
- Authenticated access through the company identity provider with multi-factor authentication enforced.
- Role-based access control aligned to least privilege.
- Periodic access reviews at the cadence the tier requires.
- Activity logging with the user identity, the timestamp, and the action.
- Incident reporting through the published security reporting channel.

Exception path:
- Handling rules that cannot be met are filed as exceptions on the engagement record with the compensating control (additional monitoring, scope reduction, network restriction, additional audit), the residual rating, the approver per the ladder in Section 3, the rationale, and a hard expiry.
- Exception expiry triggers automatic review; renewal requires fresh approval at the same residual rating ladder.
- Exception accumulation across the data estate is reported in the programme quarterly review.

7. Sharing, third-party processors, and cross-border transfers

Data leaving the organisational boundary or the jurisdiction is the highest-failure-rate part of the policy at audit. Name the rule for third-party processors, the contractual instruments required, the rule for cross-border transfers, and the documented Transfer Impact Assessment expectation. Programmes that omit this section find that auditors read transfers as undocumented, customers read transfers as unmanaged, and regulators read transfers as a breach.

Third-party processor onboarding:
- Before any tier 3 or tier 4 data is shared with a third party, a data processing agreement (DPA) is in place that names the categories of data, the categories of data subjects where personal information is involved, the purpose of processing, the security measures the processor commits to, the breach notification timeline, the subprocessor flow-down requirement, the audit right per the contractual term, the cross-border transfer mechanism if the processor processes outside the jurisdiction, the data deletion or return procedure at contract end, and the cooperation obligation for data subject rights requests and regulatory inquiries.
- A vendor security risk assessment is conducted before the DPA is signed and at the documented review cadence (typically annually for tier 4 processors; biennially for tier 3 processors; on material change for either).
- The processor onboarding evidence (signed DPA, completed vendor questionnaire, attestation reports, certifications, public trust centre evidence) is retained on the engagement record for the vendor.
- The processor is added to the third-party processor list maintained in the data inventory and the Record of Processing where applicable.

Subprocessor management:
- The third-party processor is contractually required to disclose subprocessors in advance and to flow the data processing obligations through to each subprocessor.
- The firm reviews proposed new subprocessors before they take effect; objection rights operate per the contractual term.
- The subprocessor list is reviewed at the third-party processor review cadence.

Cross-border data transfer mechanisms:
- For personal information leaving the jurisdiction, the published approved transfer mechanisms apply per jurisdiction pair:
  - GDPR adequacy decisions (Andorra, Argentina, Canada commercial organisations, Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, United Kingdom, Uruguay, and as updated by the European Commission).
  - EU-US Data Privacy Framework where the recipient is certified.
  - Standard Contractual Clauses (SCCs) at the latest published version with supplementary measures where required.
  - Binding Corporate Rules (BCRs) where the recipient is within the corporate group operating under approved BCRs.
  - Derogations under GDPR Article 49 where the limited scope and the documented basis support reliance on the derogation.
  - UK International Data Transfer Agreement (IDTA) or UK addendum to SCCs for transfers under UK GDPR.
  - Equivalent mechanisms under regional regimes (the EU-Japan adequacy decision, the EU-UK adequacy decision, the regional adequacy mechanisms under LGPD, the regional transfer rules under PDPA, the regional rules under CCPA / CPRA where applicable).
- For tier 4 personal information crossing into a jurisdiction without an adequacy decision, a documented Transfer Impact Assessment is in place that names the data, the recipient, the destination jurisdiction, the legal landscape, the supplementary measures (encryption at the boundary with the key controlled by the data exporter, pseudonymisation, contractual restrictions on government access), and the residual risk assessment.
- For non-personal-information data subject to sectoral export controls (export-controlled technology under the EAR or ITAR, regional restrictions on certain commercial data), the relevant export control rules apply in addition to this policy.

Customer sharing:
- Tier 1 data is shared with anyone.
- Tier 2 data is shared with company personnel and approved counterparties under a confidentiality agreement.
- Tier 3 data is shared with customers, vendors, and counterparties on a need-to-know basis under a documented data processing agreement or signed confidentiality agreement that flows the tier 3 handling requirements through.
- Tier 4 data is shared with customers, vendors, and counterparties on a per-decision basis under a documented data processing agreement that explicitly addresses the tier 4 obligations; the sharing event is logged on the engagement record.

Customer-controlled keys and BYOK:
- Where a customer holds the cryptographic keys that wrap the customer's data (BYOK, customer-managed keys, external key store), the customer-controlled key material is classified as tier 4 and the operational impact of customer-initiated revocation is published in the BYOK arrangement.
- The Cryptographic Key Management Policy governs the lifecycle of the customer-controlled keys; this policy governs the classification of the customer data the keys protect.

Sharing prohibitions:
- Tier 3 or tier 4 data is not shared over personal email accounts, personal cloud storage, personal chat platforms, personal social media, or unsanctioned third-party file-sharing services.
- Tier 3 or tier 4 data is not posted to public-facing forums, support communities, conference talks, or marketing materials unless the data has been documented as released under a tier change with sign-off.
- Tier 3 or tier 4 data is not embedded in third-party AI tools that train on input data unless the tool is documented as compliant with the handling rules and the third-party processor onboarding is complete.

8. Retention, legal hold, and destruction

Retention is the discipline that bounds how long the organisation holds a record; destruction is the disciplined endpoint at the end of retention. Publish the rule per data class so the retention clock has a defensible start trigger and the destruction has a documented evidence chain. The Data Retention Schedule is the per-class table that operates against this section.

Retention principles:
- Personal information is retained only for as long as necessary for the purpose for which it was collected, per GDPR Article 5 (storage limitation) and equivalent regional regimes.
- Records subject to regulatory or contractual retention obligations are retained for the period the obligation requires.
- Records subject to litigation hold or regulatory hold are retained until the hold is lifted, regardless of the underlying retention schedule.
- Records that no longer serve a documented business purpose and that are not subject to a hold or a regulatory retention obligation are deleted on the published schedule.
- Aggregate or pseudonymised derivatives may be retained beyond the underlying data retention where the aggregation or pseudonymisation reduces the re-identification risk below the threshold the privacy programme has defined.

Default retention periods (override per the Data Retention Schedule for specific data classes):
- Tier 1 public data: indefinite or at publisher discretion subject to any archive obligation.
- Tier 2 internal data: 3 to 7 years from creation or last meaningful update, depending on the data class.
- Tier 3 confidential data: per the contractual, regulatory, or business retention obligation; typical defaults include 3 to 7 years for customer records, 7 years for financial records, 6 years for HR records (or the regional employment law minimum), 90 days for transient operational logs that do not require longer retention, the platform-native retention for collaboration records subject to the e-discovery policy.
- Tier 4 restricted data: per the contractual, regulatory, or business retention obligation; typical defaults include the PCI DSS 12 months retention for cardholder data history beyond active processing, the HIPAA 6 years retention for PHI access logs, the retention period the contract names for customer-controlled data, the retention the regulatory regime requires for regulated communications.

Retention triggers:
- Account closure or contract end for customer data.
- End of employment plus the regional retention obligation for employee data.
- Project completion plus the retention obligation for project records.
- Regulatory or contractual obligation expiration for records held under such obligations.
- Lifecycle policy on storage platforms (object store lifecycle policies, log retention policies, archive policies).

Legal hold:
- The legal team or designated counsel can issue a legal hold that suspends the standard retention schedule for specific records or specific systems pending litigation, regulatory investigation, or contractual dispute.
- The legal hold names the scope (the systems, the data classes, the date range, the custodians), the duration (until-lifted), and the authority issuing the hold.
- The custodian implements the hold by suspending the deletion mechanism for the in-scope records; the steward records the hold on the inventory.
- Hold release is documented and standard retention resumes from the release date.

Destruction methods:
- Logical deletion through the platform-native delete mechanism, with verification that the record is no longer retrievable through the platform interface, the backup recovery process within the recovery window, or the archive recovery process.
- Cryptographic erasure (destroying the encryption key under which the data was encrypted, rendering the data unrecoverable) where the platform supports it for tier 3 and tier 4 data; the key destruction follows the Cryptographic Key Management Policy.
- Physical destruction of media (degaussing, shredding, pulverising, incinerating) per NIST SP 800-88 for media that has held tier 3 or tier 4 data and is being decommissioned.
- Secure overwriting for storage media that will be reused after a tier 3 or tier 4 data class is removed.

Destruction evidence:
- Destruction events for tier 3 and tier 4 records are logged with the record identifier or the record set scope, the destruction method, the named operator, the destruction timestamp, the witness signature where the regulatory regime requires, and the verification evidence.
- Destruction evidence is retained per the Audit Evidence Retention Policy.
- A bulk destruction event (decommissioning a system, retiring a data class) is recorded as a single batch event with the same evidence chain.

Backup and archive:
- Backups of tier 3 and tier 4 data are encrypted at rest using approved cryptography per the Cryptographic Key Management Policy.
- Backup retention is aligned to the underlying data retention with documented exceptions where backup retention is longer for disaster recovery purposes; backups that age beyond the published retention are deleted on the documented cadence.
- Archives of tier 3 and tier 4 data follow the same access control, labelling, and encryption requirements as live data.
- Restoration from backup is logged as a tier 3 or tier 4 access event.

9. DPIA, breach notification, and exception register

Personal information processing that is likely to result in high risk to data subjects requires a DPIA under GDPR Article 35 and equivalent regional regimes. The breach notification timeline is the regulatory clock that runs from the moment the firm becomes aware of a personal data breach. The exception register holds the residual-risk decisions for handling rules that cannot be met. The three sub-processes operate together because the DPIA identifies the risks the controls mitigate, the incident response reads against the DPIA when an incident occurs, and the exception register documents the residual-risk path when a control cannot be implemented.

Data Protection Impact Assessment (DPIA) triggers:
- A new processing activity involving tier 4 personal information or large-scale tier 3 personal information.
- A new technology that processes personal information in a way that materially changes the risk profile (a new analytics platform, a new machine learning model trained on personal information, a new AI tool that processes personal information).
- Systematic monitoring of individuals on a large scale.
- Processing of special-category personal information at scale.
- Cross-border transfers of tier 4 personal information into a jurisdiction without an adequacy decision.
- A material change to an existing processing activity that touches personal information.
- Where a regulator or a customer contract requires a DPIA for the processing activity.
- {{ADDITIONAL_DPIA_TRIGGERS}}

DPIA process:
- Scoping: name the processing activity, the data classes, the data subjects, the data flow, the lawful basis, the third parties, the cross-border transfers, the technical and organisational measures in place.
- Risk identification: identify the risks to data subjects from the processing (re-identification risk, profiling risk, decision-making risk, sharing risk, retention risk).
- Mitigation: identify the technical and organisational measures that address each risk (data minimisation, pseudonymisation, encryption, access control, retention, audit logging, contractual restrictions, opt-out paths).
- Residual risk: document the residual risk after mitigation; where the residual risk is high and cannot be mitigated to an acceptable level, prior consultation with the supervisory authority is required under GDPR Article 36.
- Sign-off: the data owner approves the residual risk; the DPO signs off on the DPIA conclusion.
- Review: the DPIA is reviewed at the documented cadence and on every material change to the processing activity.

Breach notification timelines:
- Internal incident classification: the security incident response function classifies whether the incident constitutes a personal data breach under the applicable privacy regime within hours of detection.
- DPO consultation: the DPO is consulted on every incident touching personal information within 24 hours of detection.
- Regulator notification: under GDPR Article 33, notification to the lead supervisory authority is required within 72 hours of becoming aware of a personal data breach unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; equivalent timelines apply under UK GDPR and most regional regimes; HIPAA breach notification follows the 60-day rule for breach notification to affected individuals and to HHS; sectoral regimes (PCI DSS card brand rules, NIS2 24-hour early warning followed by full notification within 72 hours, DORA major ICT-related incident reporting, SEC cybersecurity incident materiality 4-day window) operate per their published timelines.
- Data subject notification: notification to affected data subjects where the breach is likely to result in a high risk to their rights and freedoms, per GDPR Article 34 and equivalent regional regimes.
- Contractual notification: notification to customers, business partners, and counterparties per the data processing agreement breach notification timeline.
- Documentation: every breach is recorded on the incident response engagement record with the timeline, the affected data classes, the affected data subjects (where the privacy regime requires individual-level documentation), the assessment, the mitigation, and the notification evidence.

Exception register:
- Handling rules that cannot be met for a specific data class or processing activity are filed as exceptions on the engagement record.
- The exception names the data class affected, the rule that cannot be met, the compensating control, the residual rating, the approver per the Section 3 approval ladder, the rationale, and the hard expiry.
- Exception expiry triggers automatic review; renewal requires fresh approval at the same residual rating ladder.
- Exception accumulation across the data estate is reported in the programme quarterly review.
- Exceptions touching personal information are reviewed by the DPO at the documented cadence.

Prohibited shortcuts (these are the patterns that produce closed records on top of live risk):
- Skipping the DPIA on a new processing activity because the operational team believes the risk is low; the policy requires the DPIA to be the document that decides whether the risk is low.
- Filing an exception without an expiry; every exception carries an expiry, even if the expiry is the next annual review.
- Filing an exception without a compensating control; residual rating that exceeds the risk threshold without a compensating control is not approvable.
- Closing a breach incident without the regulator notification evidence where the notification obligation applied.
- Skipping the breach notification because the operational team believes no risk to data subjects exists; the assessment must be documented and signed off by the DPO.

10. Logging, monitoring, and audit evidence

A policy without logged evidence is unenforceable at audit. Publish what gets logged, who reads the log, how long the log is retained, and how the audit chain reads from detection through closure. The Audit Evidence Retention Policy is the sibling artefact that names the retention rule for the evidence this section produces.

What gets logged:
- Access to tier 3 and tier 4 data: the user identity, the access timestamp, the access purpose where the platform supports it, the action (read, write, delete, export, share).
- Classification decisions: the data class, the assigned tier, the named owner, the decision timestamp, the rationale, the linked engagement record where applicable.
- Reclassification decisions: the data class, the prior tier, the new tier, the approver, the timestamp, the rationale.
- Exception filings: the data class, the rule that cannot be met, the compensating control, the residual rating, the approver, the timestamp, the expiry.
- Exception renewals and expiries: the timestamp, the approver, the rationale.
- DPIA executions: the processing activity, the scoping, the risk identification, the mitigation, the residual risk, the sign-off, the review cadence.
- Breach incidents: the detection timestamp, the classification, the notification evidence, the closure.
- Cross-border transfers of tier 4 personal information: the data class, the destination, the transfer mechanism, the supplementary measures.
- Third-party processor onboarding and review: the DPA signing, the vendor risk assessment, the review cadence outcome.
- Retention executions: the data class, the retention trigger, the deletion timestamp, the named operator, the destruction evidence.
- Tier 4 print or export events: the user identity, the timestamp, the purpose, the destination.
- DLP enforcement events: the user identity, the timestamp, the rule triggered, the action (allow, alert, block), the disposition.

Log retention:
- Tier 4 access logs: retained per the framework requirement (typically 6 years for HIPAA PHI access logs, 12 months for PCI DSS log retention with 3 months immediately available).
- Tier 3 access logs: retained per the plan retention or the framework requirement, whichever is longer.
- Classification, reclassification, exception, DPIA, and breach incident logs: retained per the Audit Evidence Retention Policy (typically 7 years for personal information governance evidence).
- DLP enforcement logs: retained per the operational need plus the breach investigation window, with the alerted events retained at the higher logging tier.

Monitoring:
- Security operations function monitors tier 4 access patterns, DLP enforcement alerts, and unusual access events.
- Privacy function monitors the DPIA cadence, the exception register, the third-party processor review cadence, the cross-border transfer register, and the Record of Processing currency.
- GRC function monitors the classification inventory currency, the policy review cadence, the framework crosswalk currency, and the audit evidence chain.
- The operational owner publishes the programme dashboard at the quarterly cadence into the security programme review.

Audit evidence chain:
- For tier 4 data: the inventory entry, the classification decision, the labelling evidence, the access control evidence, the access logs, the retention execution evidence, the destruction evidence, and the regulator notification evidence (where applicable) form the chain a reviewer reads from the asset onboarding through the asset retirement.
- For personal information: the Record of Processing, the DPIA, the legal basis documentation, the data subject rights workflow evidence, the cross-border transfer mechanism evidence, and the breach incident evidence form the privacy chain.
- For tier 3 data: the inventory entry, the classification decision, the labelling evidence, the access control evidence, and the access logs form the chain.
- The chain is reconstructible at audit time from one operational record; tribal-knowledge recovery of the chain is a control weakness.

11. Review, revision, and acknowledgement

A policy that is never reviewed becomes a historical artefact rather than a live rule. Publish the review cadence, the material-change triggers, the revision process, and the staff acknowledgement requirement. The audit reads the published cadence against the document control history at every cycle.

Annual minimum review:
- Annual review tests whether the tier set still matches the threat environment and the regulatory horizon.
- Annual review tests whether the named example data classes per tier still match the live estate.
- Annual review tests whether the handling requirements per tier still match the technical estate.
- Annual review tests whether the framework crosswalk in Section 12 still reflects the current control catalogue.
- Annual review tests whether the role matrix in Section 3 still names the right roles for the operating model.
- Annual review tests whether the labelling discipline in Section 5 still reflects the available platform capabilities.
- The annual review outcome (no change, minor revision, major revision, full rewrite) is recorded in the document control history with the date, the reviewer, the summary, and the next review date.

Material-change triggers (off-cycle revision):
- A new regulation in scope (a US state privacy law, an EU data act, a sectoral regulation, a regional privacy regime that did not previously apply).
- An acquisition that brings in a new data estate with inherited classification rules.
- A divestiture that removes a data estate.
- A significant incident that surfaces a question the policy should have answered.
- A customer audit that requires the firm to demonstrate stricter classification discipline.
- A regulator inspection that highlights a gap.
- A privacy programme adoption (new DPIA process, new consent platform, new data subject rights workflow, new privacy enhancing technology).
- A major technology change (new cloud provider, new data platform, new collaboration suite, new sharing platform, new AI tool that processes personal information).
- A public emergence of a threat the policy should classify differently against.
- A material change to a third-party processor relationship that affects the classification scope.

Revision process:
- The policy owner drafts the revision.
- The operational owner reviews for operational feasibility.
- The DPO reviews for personal information impact.
- The head of security signs off.
- The audit committee is notified at the next scheduled meeting.
- The new version is published with the effective date, the prior version is archived per the Audit Evidence Retention Policy.

Staff acknowledgement:
- Every employee with access to tier 3 or tier 4 data acknowledges the policy on hire as part of the security onboarding programme.
- Every employee with access to tier 3 or tier 4 data acknowledges the policy at every material revision.
- Every contractor with access to tier 3 or tier 4 data acknowledges the policy on engagement and at every material revision.
- The acknowledgement evidence is retained per the Audit Evidence Retention Policy.
- Failure to acknowledge a material revision within the published deadline triggers access removal pending acknowledgement.

Training:
- Annual classification awareness training is delivered to all employees with access to tier 3 or tier 4 data.
- Role-specific training is delivered to data owners, data custodians, data stewards, the DPO, and the operational owner.
- Training completion is recorded per the Audit Evidence Retention Policy.
- New starters complete the training as part of the security onboarding programme.

12. Compliance crosswalk and signatures

The crosswalk is the artefact a customer auditor and a regulator reads first. Map the controls this policy evidences to the framework references that apply to your scope so the policy is citable in framework language as well as in operational language. The signatures close the policy as a published artefact with the authority that the rest of the policy operates against.

Framework crosswalk (extend or adapt per your scope):

ISO/IEC 27001:2022 Annex A:
- A 5.12 Classification of information: this entire policy.
- A 5.13 Labelling of information: Section 5.
- A 5.14 Information transfer: Section 7.
- A 5.34 Privacy and protection of PII: Section 9.
- A 8.10 Information deletion: Section 8.
- A 8.11 Data masking: Section 6 plus the Data Handling Standard.
- A 8.12 Data leakage prevention: Section 5 plus Section 6.

ISO/IEC 27018:2019 (personal data on public cloud): the personal information sections of this policy plus the cross-border transfer rules.
ISO/IEC 27701:2019 (privacy information management): the DPIA, Record of Processing, and breach notification sections.

NIST SP 800-53:
- RA-2 (security categorisation): Sections 4 and 5.
- SC-28 (protection of information at rest): Section 6.
- MP-3 (media marking): Section 5.
- MP-4 (media storage): Section 6.
- MP-6 (media sanitisation): Section 8.

NIST SP 800-60 (mapping types of information to security categories): Section 4.
NIST SP 800-88 (media sanitisation): Section 8.
FIPS 199 (security categorisation): Sections 4 and 5.

GDPR:
- Article 5 (data minimisation, storage limitation, integrity and confidentiality): Sections 6, 7, 8.
- Article 25 (data protection by design and by default): the entire policy.
- Article 30 (records of processing): Section 5.
- Article 32 (security of processing): Section 6.
- Article 33 (notification of personal data breach to the supervisory authority): Section 9.
- Article 34 (communication of personal data breach to the data subject): Section 9.
- Article 35 (data protection impact assessment): Section 9.
- Article 49 (derogations for specific situations): Section 7.

UK GDPR: equivalent articles to GDPR plus the UK International Data Transfer Agreement: Section 7.

HIPAA Security Rule:
- 45 CFR 164.312 (technical safeguards): Section 6.
- 45 CFR 164.314 (organisational requirements): Section 7.
- 45 CFR 164.316 (policies and procedures): the entire policy.

PCI DSS 4.x:
- Requirement 3 (protect stored account data): Sections 4, 6.
- Requirement 9.4 (control media): Section 6.
- Requirement 12.10 (incident response): Section 9.

SOC 2 Common Criteria:
- CC6.1 (logical and physical access controls): Section 6.
- CC6.7 (data classification and handling): Sections 4, 5, 6.
- CC7.2 (system monitoring): Section 10.

NIS2 Article 21 (cybersecurity risk management measures): the entire policy.
DORA Articles 8 (identification) and 9 (protection and prevention): Sections 4, 5, 6.
CISA Cybersecurity Performance Goals: the entire policy.

Document control history:

| Version | Date | Summary | Approver | Rationale |
| {{V1_VERSION}} | {{V1_DATE}} | {{V1_SUMMARY}} | {{V1_APPROVER}} | {{V1_RATIONALE}} |

Signatures:

Approved by (Programme sponsor):
Name: {{EXECUTIVE_SPONSOR_NAME}}
Role: {{EXECUTIVE_SPONSOR_ROLE}}
Signature: {{SIGNATURE_LINE}}
Date: {{APPROVAL_DATE}}

Reviewed by (Data Protection Officer):
Name: {{DPO_NAME}}
Role: {{DPO_ROLE}}
Signature: {{SIGNATURE_LINE}}
Date: {{REVIEW_DATE}}

Reviewed by (Head of Security):
Name: {{HEAD_OF_SECURITY_NAME}}
Role: {{HEAD_OF_SECURITY_ROLE}}
Signature: {{SIGNATURE_LINE}}
Date: {{REVIEW_DATE}}

Reviewed by (Policy owner):
Name: {{POLICY_OWNER_NAME}}
Role: {{POLICY_OWNER_ROLE}}
Signature: {{SIGNATURE_LINE}}
Date: {{REVIEW_DATE}}

Eight failure modes the policy has to design against

The data classification policy fails the audit read in recognisable patterns. Each failure has a structural fix the template above is designed to enforce. Read this list before you customise the template so the customisation does not weaken the discipline that makes the policy defensible.

The tier set is too coarse or too granular for the operating reality

Two-tier programmes collapse every protected record into one tier with no rule for graded handling between an internal chat channel and a customer payment record. Seven-tier programmes break the labelling discipline because no one remembers which tier a quarterly business review deck belongs in. The fix is the operationally defensible four-tier set in Section 4 with named example data classes per tier so the assignment is a lookup rather than an interpretation.

The policy is published without a maintained data inventory

The policy publishes the tier set but the firm has no maintained record of which data classes belong in which tier and where each class is stored. A reviewer asking for tier 4 examples gets a list reconstructed in the moment rather than a queryable inventory. The fix is the inventory requirement in Section 5 paired with the inventory cadence and the trigger list so the policy operates against a current record rather than an annual scramble.

Labelling is aspirational rather than enforceable

The policy requires labelling but no one actually labels documents because the discipline was never operationalised against the platforms in use. Tier 4 spreadsheets sit unlabelled in the document collaboration suite next to tier 1 marketing decks. DLP cannot enforce the label that does not exist. The fix is the platform-by-platform labelling discipline in Section 5 plus the default-label-at-folder-level mechanism plus the published alternative discipline where the platform does not support native labels.

Handling rules collapse into a single sentence per tier rather than a specification

The policy says tier 3 data is encrypted but does not name the storage discipline, the transmission discipline, the sharing discipline, the access discipline, or the disposal discipline. Operations teams fill the gap with tribal knowledge that varies by platform team. The auditor reads the gap as a control weakness. The fix is the per-tier handling specification in Section 6 with sanctioned and prohibited patterns per discipline.

Cross-border transfers are undocumented

Tier 4 personal information moves between jurisdictions under contracts that were not reviewed against the transfer mechanism rules. The regulator reads the transfers as a breach of the cross-border transfer rules; the customer reads the transfers as unmanaged. The fix is the per-jurisdiction transfer mechanism table in Section 7 plus the documented Transfer Impact Assessment requirement for tier 4 transfers into jurisdictions without adequacy.

Retention runs on platform defaults rather than on a published schedule

Data accumulates beyond the retention obligation because no one published the schedule. Personal information that should have been deleted three years ago is still queryable; financial records that should have been retained for seven years are deleted at the five-year mark by an aggressive lifecycle policy. The fix is the Data Retention Schedule sibling artefact referenced from Section 8 with the per-class retention period, the trigger, and the destruction discipline.

The DPIA discipline is reactive rather than scheduled

DPIAs happen only after an incident or a regulator query, never before a new processing activity goes live. The firm cannot demonstrate proactive privacy impact assessment to the regulator or the customer. The fix is the DPIA trigger list in Section 9 plus the operational owner accountability for scheduling DPIAs as part of the new-processing-activity intake.

Exceptions accumulate without expiry or compensating control

Handling rules that cannot be met get filed as exceptions but the exceptions never expire and never name a compensating control. The exception register becomes a graveyard of unresolved risk. The fix is the Section 9 requirement that every exception has an expiry, a compensating control, a residual rating, and a named approver per the Section 3 approval ladder, plus the periodic review that surfaces accumulation.

Ten questions the quarterly governance review has to answer

Operational review keeps the programme on top of tier 3 and tier 4 findings, DLP enforcement events, exception flow, retention executions, and third-party processor posture. Governance review answers whether the policy is delivering durable classification discipline or accumulating residual risk the audit will read as policy drift. Run these ten questions at every quarterly review and capture the answers in the governance record.

1.What is the closure rate on findings touching tier 3 and tier 4 data per discipline over the rolling twelve months, and is the trend line up, flat, or down.
2.How many findings breached the SLA in the period, what was the breach reason distribution (capacity, dependency, ownership, exception-pending), and what is the structural fix landing.
3.How many active exceptions are in the register for tier 3 and tier 4 handling rules, broken down by residual rating, and how many are approaching expiry within 60 days.
4.How many new processing activities went through the DPIA process in the period, how many bypassed the trigger criteria, and how many DPIAs identified a residual high risk requiring prior consultation with the supervisory authority.
5.How many tier 3 or tier 4 access events were logged in the period that triggered a security alert, and what was the disposition rate.
6.How many DLP enforcement events were logged in the period, broken down by tier and by enforcement action (alert, block, allow with exception), and what is the rule tuning trend.
7.How many third-party processors were onboarded or reviewed in the period, how many vendor risk assessments produced findings, and what is the residual processor risk distribution.
8.How many cross-border transfers of tier 4 personal information were documented in the period, and is every transfer covered by an active transfer mechanism plus, where required, a current Transfer Impact Assessment.
9.How many retention executions completed in the period, how many destruction events recorded the full evidence chain, and how many records aged beyond the published retention without explanation.
10.Has any framework, regulation, customer contract, threat environment, technology change, or incident in the period triggered policy review, and is the review on schedule.

How the policy pairs with SecPortal

The template above is copy-ready as a standalone artefact. If your team already runs finding tracking, remediation, and compliance evidence on a workspace, the lifecycle of findings that touch classified data becomes the byproduct of the work rather than a separate spreadsheet. SecPortal pairs every detection to an engagement record through findings management, so the triage classification, the owner-of-record assignment, the remediation evidence, the verification result, and the closure timestamp live on one record rather than across tickets, chat threads, and a closed-out runbook. The code scanning feature runs Semgrep against connected repositories with rules that detect unsafe data handling (hardcoded PII patterns, weak cryptography on personal data, insecure deserialisation, SQL injection that touches sensitive tables, logging of sensitive values), so the detection surface the policy declares in Section 6 is observable rather than asserted. The repository connections feature carries the encrypted git provider tokens that authorise the scan.

The authenticated scanning feature runs DAST against pages behind the login screen that touch regulated data, with encrypted credential storage protecting the test credentials at rest with AES-256-GCM, so authenticated scanning against pages handling regulated data does not depend on a shared password manager. The external scanning feature across 16 modules covers exposed cloud storage, leaked credentials, subdomain enumeration, certificate transparency mining, TLS configuration, and security headers on the verified perimeter that touches regulated data. The bulk finding import feature pulls in DSPM, CSPM, DLP, and third-party pentest findings through CSV with custom column mapping so the backlog reads from one queue rather than from four scanner consoles.

The finding overrides primitive holds the suppression decisions for documented test fixtures, vetted samples, and false positives with rationale and an expiry on accepted-risk decisions, so the suppression audit is queryable rather than reconstructible. The activity log captures the timestamped chain of state changes by user, so the elapsed time between detection, triage, remediation, verification, and closure is observable rather than asserted. The continuous monitoring feature schedules the recurring scans so changes to systems touching classified data are detected on the published cadence rather than the next manual run.

The document management feature retains the policy file, the data inventory baseline, the data flow diagrams, the DPIA artefacts for high-risk processing, the data retention schedule, the third-party processor list, the regulator correspondence, and the revision history alongside the operational record, so the policy version and the privacy evidence in force at any reporting cycle are reconstructible from one record. The team management feature carries role-based access control that gates the severity override path, the exception approval ladder, and the policy publishing authority referenced from Section 3. The multi-factor authentication enforcement at the workspace boundary protects access to the operational record that carries the classified-data finding trail. The compliance tracking feature maps classified-data findings and the surrounding controls to ISO 27001, ISO 27018, ISO 27701, SOC 2, PCI DSS, HIPAA, GDPR, and NIST framework expectations with CSV export, so the framework crosswalk in Section 12 reads against the live record rather than a separate evidence spreadsheet. The AI report generation workflow produces leadership, privacy steering committee, and audit summaries from the same engagement data so the audit committee read and the operational read are the same record.

For the operational workflow that pairs classified-data findings to the wider finding lifecycle, see vulnerability finding state lifecycle; for the SLA discipline see vulnerability SLA management; for the exception path see vulnerability acceptance and exception management; for the verified-closure discipline see security finding fix verification; for the audit fieldwork shape see audit fieldwork evidence request fulfillment; for the customer assurance shape see customer security evidence room; and for the cross-framework reconciliation see control mapping and cross-framework crosswalks. For the vulnerability education that pairs with this policy, see the sensitive data exposure, cloud bucket misconfiguration, and information disclosure encyclopedia entries. For the framework anchor, see the ISO 27001 framework page (Annex A 5.12 and 5.13), the ISO 27018 framework page (personal data on public cloud), ISO 27701 framework page (privacy information management), NIST SP 800-53 framework page (RA-2 and SC-28), GDPR framework page (Articles 5, 25, 30, 32), HIPAA framework page, and the PCI DSS framework page (Requirement 3).

Explicit honest scope: SecPortal does not classify data, does not operate a data discovery engine that scans datastores for sensitive content patterns, does not operate a DLP enforcement plane, does not run a privacy-platform consent management workflow, does not issue data subject access request fulfilment letters, does not integrate with the data catalogue or the metadata management system, does not integrate with Jira, ServiceNow, Slack, SIEM, or SOAR, and does not host or process the classified data itself. The data classification, the data inventory, the labelling discipline, and the DLP enforcement live in the systems the data sits in; SecPortal carries the operational evidence and the finding lifecycle the policy runs against.

Buyer and operator pairing

The data classification policy is the artefact CISOs and security leaders, internal security teams, GRC and compliance teams, data security teams, AppSec teams, cloud security teams, platform engineering teams, and security architects publish when a programme has to survive an external audit, a customer assurance review, and a regulator inspection on the same artefact. External providers (virtual CISOs, compliance consultants, security consultants) use the same template to give clients a per-engagement data classification policy that is consistent with the framework expectations rather than a one-off slide deck per programme.

Loading tool...

Related features

Vulnerability management software that tracks every finding

Find vulnerabilities before they ship

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Bulk finding import bring your scanner data with you

Finding overrides that survive every scan cycle

Monitor continuously catch regressions early

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

AI-powered reports in seconds, not days

Vulnerability finding state lifecycle

Vulnerability SLA management

Vulnerability acceptance and exception management

Vulnerability fix verification

Audit fieldwork evidence request fulfillment

Customer security evidence room workflow

Cross-framework control mapping

Security leadership reporting

Compliance audits

Run the classified-data finding lifecycle on the live record, not on a side spreadsheet

SecPortal carries findings touching tier 3 and tier 4 data on a workspace engagement record with the detection scan, the triage rationale, the suppression decision, the remediation evidence, the verification scan, and the closure timestamp on one audit-readable record. Free plan available.

Get Started Free

No credit card required. Free plan available forever.

Data Classification Policy Templatetwelve sections for tier definitions, inventory discipline, labelling, handling per tier, third-party transfers, retention, DPIA, and a defensible sign-off

Twelve sections that turn data classification into a defensible policy

1. Policy charter and authority

2. Scope and information assets in scope

3. Roles, responsibilities, and the approval ladder

4. Classification tiers and example data classes

5. Labelling, metadata, and inventory discipline

6. Handling rules per tier

7. Sharing, third-party processors, and cross-border transfers

8. Retention, legal hold, and destruction

9. DPIA, breach notification, and exception register

10. Logging, monitoring, and audit evidence

11. Review, revision, and acknowledgement

12. Compliance crosswalk and signatures

Eight failure modes the policy has to design against

The tier set is too coarse or too granular for the operating reality

The policy is published without a maintained data inventory

Labelling is aspirational rather than enforceable

Handling rules collapse into a single sentence per tier rather than a specification

Cross-border transfers are undocumented

Retention runs on platform defaults rather than on a published schedule

The DPIA discipline is reactive rather than scheduled

Exceptions accumulate without expiry or compensating control

Ten questions the quarterly governance review has to answer

How the policy pairs with SecPortal

Buyer and operator pairing

Related features

Vulnerability management software that tracks every finding

Find vulnerabilities before they ship

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Bulk finding import bring your scanner data with you

Finding overrides that survive every scan cycle

Monitor continuously catch regressions early

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

AI-powered reports in seconds, not days

Vulnerability finding state lifecycle

Vulnerability SLA management

Vulnerability acceptance and exception management

Vulnerability fix verification

Audit fieldwork evidence request fulfillment

Customer security evidence room workflow

Cross-framework control mapping

Security leadership reporting

Compliance audits

Run the classified-data finding lifecycle on the live record, not on a side spreadsheet

Twelve sections that turn data classification into a defensible policy

1. Policy charter and authority

2. Scope and information assets in scope

3. Roles, responsibilities, and the approval ladder

4. Classification tiers and example data classes

5. Labelling, metadata, and inventory discipline

6. Handling rules per tier

7. Sharing, third-party processors, and cross-border transfers

8. Retention, legal hold, and destruction

9. DPIA, breach notification, and exception register

10. Logging, monitoring, and audit evidence

11. Review, revision, and acknowledgement

12. Compliance crosswalk and signatures

Eight failure modes the policy has to design against

The tier set is too coarse or too granular for the operating reality

The policy is published without a maintained data inventory

Labelling is aspirational rather than enforceable

Handling rules collapse into a single sentence per tier rather than a specification

Cross-border transfers are undocumented

Retention runs on platform defaults rather than on a published schedule

The DPIA discipline is reactive rather than scheduled

Exceptions accumulate without expiry or compensating control

Ten questions the quarterly governance review has to answer

How the policy pairs with SecPortal

Buyer and operator pairing

Data Classification Policy Template
twelve sections for tier definitions, inventory discipline, labelling, handling per tier, third-party transfers, retention, DPIA, and a defensible sign-off