Data Classification Policy

LEAP -- Data Classification Policy

Document Number POL-GL-COM-DATAC-V1.0
Target audience <<intended recipients>>
Effective Date Twelve months

Cover page layout

Contents

  • 1. Purpose
  • 2. Scope
  • 3. Definitions
  • 4. Roles and Responsibilities
  • 5. Data Classification Scheme
  • 6. Required Security Controls
  • 7. Implementation Requirements
  • 7.1. AWS Tagging
  • 7.2. System and Applications
  • 7.3. Data Lifecycle
  • 8. Classification Guide
  • 9. Any References
  • 10. Related documents (optional)
  • 11. Policy Exceptions
  • 12. Policy Enforcement
  • 13. Policy Monitoring
  • 14. Awareness & Communication
  • 15. Version History

Purpose

This policy establishes a standardised data classification framework for LEAP to ensure that information assets are consistently identified, labelled, protected, and handled according to their sensitivity and business value. It supports legal, regulatory, contractual, and audit obligations and enables risk-appropriate controls across people, process, and technology.

Scope

This policy applies to all LEAP entities, employees, contractors, vendors, and systems that store, process, transmit, or access LEAP information, including but not limited to:

  • Production and non-production environments in LEAP's AWS and other cloud platforms
  • End-user computing, collaboration tools, and document repositories
  • LEAP applications, APIs, and data stores (e.g., S3, DynamoDB, RDS)
  • Paper records, removable media, and backups

Definitions

  • Information Asset: Data or records with value to LEAP's business operations or legal obligations.
  • Data Owner: Senior role accountable for a data set's classification, access, and lifecycle outcomes.
  • Data Custodian: Technical role implementing controls (e.g., DevOps, IT Ops, Engineering).
  • PII/Personal Data: Any data relating to an identified or identifiable individual, including special/sensitive categories under applicable laws.
  • Tagging: Applying standardised labels/metadata to resources and datasets to indicate classification.

Roles and Responsibilities

  • Leadership: Approves this policy and major exceptions, ensures adequate resourcing.
  • GRC Team: Owns the policy, provides guidance, assures compliance, and coordinates audits.
  • Data Owners: Classify datasets, approve access, ensure appropriate controls across lifecycle, annually attest classification and access.
  • Data Custodians (IT Ops, DevOps, Engineering): Implement technical controls, tagging, and monitoring, maintain inventories.
  • All Staff: Handle information in line with assigned classification, report suspected misclassification or policy violations.

Data Classification Scheme

All information assets must be assigned one of the following classifications.

Classification Description Typical Examples
Sensitive Data with the most limited access, requiring a high degree of confidentiality, integrity, and availability. Unauthorised disclosure or alteration could cause severe harm to LEAP or its clients. This includes customer data and Personally Identifiable Information (PII). Client matter data, special/sensitive personal data, authentication secrets, production credentials, security keys, regulated financial records tied to clients.
Confidential Internal data whose unauthorised disclosure could cause material harm to LEAP's operations, finances, legal standing, or reputation. Internal financials, internal strategy documents, internal security procedures, incident response playbooks, vendor assessments.
Private A department data not intended for broad internal distribution and protected for privacy, contractual, or P&C reasons. HR records, performance reviews, compensation data, employee health or leave information (non-public).
Proprietary Information disclosed outside LEAP on a limited basis or that could reduce competitive advantage if broadly disclosed. Source code repositories, configuration files, technical specifications, non-public product roadmaps, Marketplace integration details.
Public Data approved for public release. Unauthorised disclosure causes minimal or no harm. Published marketing content, website materials, publicly released policies, job postings, product brochures.

Required Security Controls

Area Sensitive Confidential Private Proprietary Public
Access Control Strict least-privilege, role-based access, MFA, quarterly access reviews, break-glass approvals Least-privilege, role-based, MFA, semi-annual access reviews Need-to-know, role-based, MFA where feasible Role-based, approval to external share No restriction beyond authenticity of source
Encryption Mandatory encryption in transit and at rest. Encryption in transit and at rest Encryption in transit, at rest strongly recommended Encryption in transit, at rest recommended Encryption in transit recommended
Storage/Location Approved secure stores only, production segments, no non-prod without masking Approved internal stores Restricted HR/functional stores Approved internal repos or controlled shares Public repositories approved by Communications/Marketing
Data in Non-Prod No raw production data, use synthetic/masked datasets Mask where feasible, owner approval required Mask where feasible Owner approval Not applicable
Sharing/Transfer Approved channels only, vendor DPAs required Approved channels, DLP where available Approved HR/functional channels Limited distribution, NDAs as required Public channels as approved
Logging/Monitoring Security logging with alerting and retention, anomaly detection Security logging and periodic review Logging per system standard Logging per system standard Minimal
Backup/Restore Backups encrypted, tested restores, segregation from non-sensitive data Encrypted backups, periodic restore tests Backups per function, protect HR data Backups per team standard Optional per business need
Disposal Cryptographic erasure or secure deletion, vendor attestation if external Secure deletion method Secure deletion method Standard deletion As needed

Implementation Requirements

AWS Tagging

All AWS resources that store or cache data must be tagged with Key: DataClassification and Value equal to one of: Sensitive, Confidential, Private, Proprietary, Public.

  • Mandatory resources to tag: S3 buckets, DynamoDB tables, RDS instances. Extend to EBS volumes, EFS, ElastiCache, OpenSearch, data pipelines, and any service persisting data.
  • Enforcement: Use preventive controls (SCPs/IAM guardrails) and detective controls (Config rules) to block or alert on untagged/mis-tagged resources.

System and Applications

  • Application teams must document the highest classification of data the system stores or processes and align controls accordingly.
  • APIs must maintain internal endpoint-level data classification labels in management consoles, classification is not displayed externally.
  • Change management must include classification impact assessment for new data fields or integrations.

Data Lifecycle

  • On creation/ingestion: Assign classification, set owners and intended storage/retention profile.
  • During processing: Ensure encryption, access control, and logging consistent with the highest classification handled.
  • Sharing/third parties: Complete vendor due diligence, ensure DPAs/SCCs where applicable, restrict access to minimum necessary.
  • Archival/disposal: Follow secure deletion methods aligned to classification and legal/contractual retention requirements.

Classification Guide

Use the prompts below and choose the highest risk answer encountered.

  1. Does the data identify a person, or could it reasonably identify a person? If yes, classify at least Sensitive if special/sensitive category, otherwise at least Confidential.
  2. Would unauthorised disclosure materially harm clients, LEAP's legal standing, or competitive position? If yes, Confidential or Proprietary.
  3. Is it HR or personnel-related data? Typically Private.
  4. Is it intended and approved for public release? If yes, Public, otherwise higher.

Any References

  • ISO/IEC 27001:2022
  • SOC 2

Related documents (optional)

  • Information Security Policy
  • LEAP - Third-Party Risk Management SOP
  • Backup and Recovery Standards
  • LEAP - Access Control Policy
  • LEAP - Incident Response SOP

Policy Exceptions

Exceptions in this policy will be risk-assessed by LEAP's Leadership Committee with valid business justification and Policy Owner's approval. Exceptions will be time bound.

Policy Enforcement

Any LEAP employee, contractor, third-party found to have violated any part of this policy may be subject to HR disciplinary action, up to and including termination of employment.

Policy Monitoring

Compliance with this policy will be monitored through periodic reviews, audits, and management oversight.

Awareness & Communication

This policy is an organisational record. A copy of LEAP security policies is made available to all staff/business units currently employed, or when they join LEAP. Employees requiring further information on any aspects of this Policy should discuss their needs with Trust at LEAP Legal Software trust@leaplegalsoftware.com. Any changes or updates to the policy are immediately communicated to Team Governance, Risk and Compliance (GRC).

Version History

Version Number Date Section Changes Author Approver
1.0 <<enter date>> Initial Release <<Title>> <<Title>>