Cybersecurity · Data security
Knowing where the data is, and proving who can reach it
Discovery and classification, encryption and key control, isolation enforced at the database layer, and recovery that has been exercised. Most data programmes stall at the inventory. We build the controls and the evidence at the same time.
Where this starts
The inventory is not the control
Nearly every organisation we meet has a data map somewhere. Very few can show, on the day they are asked, which systems hold personal data, who holds standing access to it, whether the test environment copy is masked, and whether the backup could really be restored if the primary were encrypted by someone else tonight. The gap is not awareness. It is that the answer lives in people rather than in the system.
What we usually find
- Production data copied into test environments unmasked, then forgotten
- Encryption enabled with provider-held keys that have never been rotated
- Multi-tenant data separated by an application filter rather than by the database
- Backups that have never been restored, or that an attacker holding administrator rights could delete
- Retention policies written down and enforced by nothing
- Warehouse access granted broadly because narrowing it was going to be difficult
Our position
A backup you have not restored is a belief. A retention policy nothing enforces is a liability with a date on it.
What the work covers
From discovery through to deletion
The lifecycle is the scope. A control at one stage without the others tends to move risk rather than reduce it, which is why so much data work feels like effort without a change in exposure.
Discovery and classification
Automated discovery across databases, object storage, warehouses and the quiet corners where copies accumulate, with classification applied as tags that downstream controls can act on rather than as a register nobody reads twice.
Encryption and key control
Encryption in transit and at rest is the straightforward part. The meaningful questions are who holds the keys, how rotation actually happens, and whether a customer contract requires customer managed keys. We implement to the commitment you have made rather than to the platform default.
Tenant isolation
Isolation enforced at the database layer through row level security or separate schemas, rather than by a filter the application is trusted to remember. One missing clause in one query should not be a cross-customer data breach, and with the right structure it cannot be.
Non-production data
Masking, subsetting and synthetic generation, so the test environment stops being the softest copy of your production data and the largest unmanaged exposure in the estate. This is frequently the single highest-value change available.
Monitoring and exfiltration
Database activity monitoring and egress controls tuned to what normal actually looks like in your systems, focused on the queries and transfers that would matter, rather than alerting on volume for its own sake.
Backup integrity and recovery
Immutable and isolated copies, backup credentials separated from production administration, and a restore exercised on a schedule with the recovery time measured and reported rather than estimated.
How it stays fixed
Data controls fail quietly
Nothing breaks when classification stops running or a retention job is disabled. These are the points where we make the controls assert themselves instead.
Classification
Discovery runs on a schedule and new stores inherit classification at creation, so an unclassified database becomes an exception that surfaces rather than the normal state of things.
Provisioning
A new environment cannot be created from a copy of production unless it passes through the masking pipeline. The safe path is the only path, which is why it gets used.
Access
Standing access replaced with time-bound grants, so entitlement decays by default and an access review stops being an archaeology exercise.
Retention
Deletion executed by a job against the policy, with an audit record, rather than depending on somebody remembering a schedule during a busy quarter.
Recovery
Automated restore tests into an isolated environment, integrity verified, and the time to recover recorded as a metric that trends rather than a number someone recalls.
What you are left holding
- A live data inventory with classification other controls consume
- Isolation enforced in the database, with tests that prove it every release
- A masking pipeline every non-production environment passes through
- Restores exercised on a schedule, with a recovery time you can quote
- Retention and deletion running as jobs, with evidence attached
Start with one question
If your primary database were encrypted by an attacker tonight, how long until you were serving customers again, and how do you know? We work backwards from your answer.