Determining Data Security Controls
When securing data across its lifecycle, the controls chosen must be deliberate, layered, and auditable. The decision space clusters around four levers:
- Baselines — the minimum, uniform protections that every relevant asset must meet
- Scoping & Tailoring — deciding which controls from a standard actually apply (scoping) and how to adapt them to your environment (tailoring)
- Standards Selection — mapping to ISO/IEC 27001, NIST SP 800-53, COBIT, and sector rules like HIPAA/PCI DSS/GDPR
- Cryptography — selecting and operating encryption for data at rest, data in transit, and data in use, with sound key management
Baselines — The First Layer of Defence
Baselines are predefined, standardised configuration and control sets that establish a minimum level of protection everywhere they apply. They provide consistency — a floor you cannot fall below, with no "forgotten corner" running on default credentials or unencrypted disks.
Examples of baseline controls:
- Password policy minimums (length, complexity, reuse rules)
- Firewalls default-deny with explicit allow-lists
- Encryption required for data in transit and data at rest
- Enforced least privilege across user roles
Baseline considerations to decide explicitly: which systems share one baseline, whether one baseline applies everywhere or tiers are needed, and the target security level calibrated to asset value, regulations, and the threat landscape.
Practical sources: ISO/IEC 27001, NIST CSF / 800-53, COBIT (international); HIPAA, PCI DSS, GDPR (sector-specific).
Scoping and Tailoring
- Scoping: From the chosen framework, pick only the controls that actually apply. Selecting AC-18 Wireless controls from NIST is not "choosing NIST" — it's scoping the relevant parts. Remove non-applicable items entirely.
- Tailoring: Modify applicable controls to fit your operating reality and risk. Example: AC-18(1) adapted to mandate MFA and strongest practical Wi-Fi encryption in high-security zones.
First decide "what applies," then adapt for precision. Don't gold-plate low-value assets. Don't under-defend crown jewels. Asset inventory and classification are the starting gun.
Data at Rest (DAR)
What needs protection: databases, backups/tapes, offsite/cloud storage, password stores, IP, finance/health records — everything that sits still but still matters.
How to Protect
- Cryptography: Symmetric/asymmetric schemes; FDE vs file/volume-level encryption; server-side vs client-side; BYOK/HYOK where appropriate
- Key Management: Secure generation, storage, rotation, escrow/recovery, strict access, HSMs where needed
- TPM (Trusted Platform Module): Tamper-resistant crypto chip; secure key storage; attested boot; often paired with BitLocker-style FDE
- SED (Self-Encrypting Drive): Inline hardware encryption; transparent to users; keys resident on device with enterprise-grade admin operations
Data in Transit (DIT)
End-to-End Encryption (E2EE)
Encrypted on the sender's device; decrypted only by the recipient. Payload is protected across the entire path — routing metadata (headers) may remain visible for delivery. Examples: TLS for applications, S/MIME/PGP for email, modern secure messengers.
Link Encryption
Encrypts traffic between network devices across each hop (router-to-router, MPLS backbone, VPN tunnel mode). Each node decrypts and re-encrypts — strong path confidentiality, but a compromised hop can see plaintext. Key management complexity rises with hops.
Combination Approach
Use both when the path is hostile or regulated: link encryption to blind the route, plus E2EE so intermediaries never see payloads.
Transport mode — encrypts payload only. Tunnel mode — encrypts both payload and headers.
Data in Use (DIU)
If you cannot encrypt during processing, reduce exposure through other means:
- Static masking: Scrub or transform PII on resting data — typically for non-production environments
- Anonymisation: One-way, irreversible — data leaves GDPR scope
- Pseudonymisation: Reversible via a separate key — GDPR-friendly where re-linking is necessary
- Dynamic masking: Present redacted views while data is being accessed (e.g., "XXXX-XX-6789")
- Tokenisation: Swap sensitive fields for format-preserving tokens stored in a vault
- DRM & Watermarking: Constrain document/media use; embed ownership trails
- DLP/DAM: Observe and enforce policy at endpoints, databases, and egress points
Retention, Legal Hold, and eDiscovery
- Data Standards: Define the objects and fields your organisation collects and how they must be handled for accuracy and compliance.
- Legal Hierarchy: International → national → regional → local. Your data standards must honour all applicable layers.
- Legal Hold: When litigation, audit, or regulatory action is anticipated, you must preserve relevant data — even if your retention schedule would normally delete it. Legal hold overrides retention.
- eDiscovery: Identify, collect, preserve, search, and produce electronically stored information (ESI) as evidence. Expect chain-of-custody rigour.
Marking, Labelling, Handling, and Media
- Labels (machine-enforceable): Drive automated decisions — block, encrypt, apply DRM.
- Markings (human-readable): Cue human behaviour — "CONFIDENTIAL – DO NOT FORWARD."
Mark what matters: sensitivity, encryption status, point of contact, retention end date. Default to caution — if you find unlabelled media, assume highest sensitivity until analysis says otherwise.
Handling: Limit access to designated custodians; train them; never leave sensitive media unattended; encrypt backups; maintain destruction logs.
Data Remanence and Sanitisation
Residual data persists after deletion. Choose a sanitisation method based on classification, reuse intent, and environment:
- Clear: Overwrite (zeroisation, multi-pass). Stops casual recovery — not lab-grade forensics.
- Purge: Stronger than clear (e.g., degauss magnetic media). Near-impossible recovery.
- Destroy: Physical annihilation — shred, incinerate, disintegrate, acid. No reuse possible.
- Crypto-shredding / Crypto erasure: Permanently destroy encryption keys so ciphertext becomes useless.
- Cryptographic Erase (CE): SED-native key destruction that renders existing data unreadable while allowing media reuse.
Public data → dispose normally. Low/Moderate leaving org → purge. High → destroy. Reuse desired? Prefer purge/CE. Top-secret → destroy. Always validate the outcome and document the method for audit.
Cloud Nuances
- In motion: TLS/IPsec everywhere to and from the cloud
- At rest: Provider encryption — consider customer-managed keys (BYOK/HYOK) for higher assurance
- Detect exfiltration: Use DLP and Database Activity Monitoring to catch shadow data flows
- Resilience: Dispersion (replication across sites) and fragmentation/sharding — secured by the same labelling, key, and retention rigour you'd demand on-premises
Brain Ticklers
Q1. Neuromesh plans to resell older encrypted SEDs from the developer fleet. The disks contain anonymised analytics data labelled "Internal." What's the best sanitisation approach?
- Clear the drives with single-pass zeroisation
- Purge using degaussing and then reuse
- Use Cryptographic Erase (CE) on each SED and verify, then resell
- Physically destroy the drives to eliminate remanence risk
Q2. A product team syncs masked customer data from production to a cloud dev tenant. They require occasional re-link to originals for defect triage under GDPR. Which technique aligns best?
- Anonymisation
- Pseudonymisation
- Static masking that cannot be reversed
- Tokenisation with no mapping table
Q3. Anas is deciding between end-to-end encryption and link encryption for a new partner connection over an MPLS backbone. The partner insists that no intermediate device should ever see plaintext payloads. Best choice?
- Link encryption only
- End-to-end encryption only
- Combine link encryption with end-to-end encryption
- Rely on private addressing and QoS instead of encryption
Q4. Backups of payroll data are shipped offsite weekly. A litigation hold is issued for a date range intersecting those backups. Which action is most correct?
- Continue standard retention; legal hold applies only to production
- Suspend deletion and preserve relevant backup sets, documenting chain of custody
- Restore all backups and export to legal immediately
- Delete older tapes to make room; legal hold won't apply retroactively
Q5. A roaming admin laptop with TPM-backed FDE is stolen. Keys are sealed to platform state with secure boot. What residual risk remains most realistic?
- Offline decryption with standard tools
- Bypass via swapping RAM into a donor system
- Credential theft through remote phishing after the theft
- TPM revealing the key if the attacker reads NVRAM directly
- Baselines set the floor — no asset falls below minimum controls
- Scope first (what applies), then tailor (how to adapt)
- DAR: FDE, key management, TPM, SED, BYOK/HYOK
- DIT: E2EE protects payload end to end; link encryption protects each hop
- Combine both on hostile or regulated paths
- Legal hold overrides retention schedules — always
- Clear → Purge → Destroy — choose based on classification and reuse intent
- Crypto erasure (CE) allows SED reuse; crypto-shredding destroys keys permanently
- Labels are machine-enforced; markings are human-readable — you need both