Cybersecurity · Data security
Know where your data is, and prove who can access it
We find and classify your data, manage encryption and keys, separate customer data at the database level, and test your recovery. Most data security programmes stop once the inventory is complete. We build the controls and the evidence at the same time.
Where this starts
Knowing where data is does not protect it
Almost every organisation we meet has a data map somewhere. Very few can show, on the day they are asked, which systems hold personal data and who has permanent access to it. Few can say whether the copy in the test environment has been anonymised, or whether their backups could really be restored if an attacker encrypted their main systems tonight. The problem is not a lack of awareness. It is that the answers are held in people’s heads rather than in the systems.
What we usually find
- Live data copied into test environments without being anonymised, then forgotten
- Encryption switched on, but with keys held by the provider that have never been changed
- Customer data kept apart only by the application, rather than by the database itself
- Backups that have never been restored, or that an attacker with administrator rights could delete
- Data retention policies that are written down but not enforced
- Broad access to the data warehouse, because restricting it seemed too difficult
Our position
Until you have restored a backup, you cannot be sure it works. A retention policy that nothing enforces is a risk waiting to be discovered.
What the work covers
From finding data to deleting it
We cover the full life of your data. A control at one stage without the others usually moves the risk elsewhere rather than reducing it. That is why so much data security work takes effort without actually lowering exposure.
Finding and classifying data
We automatically search databases, file storage, data warehouses and the less obvious places where copies build up. Each item is tagged with a classification that other controls can act on, rather than recorded in a register that nobody reads.
Encryption and key control
Encrypting data in transit and at rest is the easy part. The important questions are who holds the keys, how they are changed, and whether a customer contract requires the customer to control their own keys. We implement what you have committed to, rather than the platform’s default settings.
Separating customer data
We separate each customer’s data within the database itself, using row-level security or separate schemas. We do not rely on the application remembering to filter every query. With the right structure, one mistake in one query cannot expose one customer’s data to another.
Test and development data
We anonymise, reduce or generate test data, so your test environment is no longer an unprotected copy of your live data. This is often the single most valuable change we can make.
Monitoring and data leaks
We monitor database activity and outbound transfers, tuned to what normal looks like in your systems. We focus on the queries and transfers that would really matter, rather than raising alerts on volume alone.
Backups and recovery
We set up backups that cannot be changed or deleted and are kept separate from your main systems, with their own credentials. Restores are tested on a schedule, and the recovery time is measured and reported rather than estimated.
How it stays fixed
Data controls fail without anyone noticing
Nothing visibly breaks when data classification stops running or a retention job is switched off. These are the points where we make sure the controls keep working, and that you know if they stop.
Classification
Data discovery runs on a schedule, and new data stores are classified as soon as they are created. An unclassified database is flagged as an exception rather than being normal.
Provisioning
A new environment cannot be created from a copy of live data unless the data is anonymised first. The safe route is the only route, which is why it gets used.
Access
Permanent access is replaced with access that expires after a set time. Permissions shrink by default, and access reviews no longer involve digging through years of history.
Retention
An automated job deletes data according to the policy and keeps an audit record. It does not depend on someone remembering to do it during a busy period.
Recovery
Restores are tested automatically in a separate environment and checked for completeness. The recovery time is tracked over time, rather than being a figure someone remembers.
What you are left with
- An up-to-date data inventory, with classifications that other controls use
- Customer data separated in the database, with tests that prove it on every release
- An anonymisation process that every test environment goes through
- Restores tested on a schedule, with a recovery time you can quote
- Automated retention and deletion, with evidence attached
Start with one question
If an attacker encrypted your main database tonight, how long would it take before you were serving customers again, and how do you know? We start from your answer.