Kode-1
Data security

Know what sensitive data you hold, and who can actually reach it

Three questions decide whether your data is defensible: what do we hold, where does it live, and who can open it today. Most organisations can answer in outline and not in the specifics that let anyone act. We find the answer, evidence it, and remediate the exposure while the work runs.

The exposure almost nobody can describe yet

Data spreads faster than the controls around it. Stores are created for a project and outlive it. Access is granted for a role someone has since left. Sharing links are opened to the whole organisation because that was the quickest way to unblock a deadline. None of it is negligence; it is the residue of years of ordinary work. The result is an estate where the gap between who can reach sensitive data and who should reach it has never been measured, and where the honest answer to a board question about exposure is an estimate. The uncomfortable part is that the same gap is invisible to your existing controls: loss-prevention and access tooling can only enforce policy on data that has been found, understood and labelled, so an unclassified store is not protected by a policy that never sees it.

Five things have to be true, in this order

1. Discovery

  • Every repository in scope, cloud and on-premises, structured and unstructured
  • Collaboration, messaging and file-sharing surfaces, not just the database estate
  • Found by what the content is, rather than by hand-written patterns that miss what they were not told to look for

2. Classification

  • A classification policy that fits how your business actually describes its own information
  • Labels applied consistently across the tools that manage access and sharing
  • New data sorted as it arrives, so the picture does not decay the week after the project ends

3. Access governance

  • What acceptable use looks like, written down, including how exceptions get handled
  • Excessive permissions, stale accounts and public or organisation-wide links surfaced and cut back
  • Access made intentional rather than accidental, and auditable afterwards

4. Retention

  • A retention policy mapped to the data it governs, with a cleanup plan that names owners
  • Expired and redundant data archived or destroyed, duplicates included
  • Rules that execute automatically, rather than a policy that exists on paper

5. Monitoring and control

  • Alerting on oversharing, misclassification and expired records
  • Unusual behaviour around sensitive data escalated to the people who can act
  • Reporting a board, a regulator or an insurer will accept as evidence

Copilot moved this up everyone's list

Assistants inherit the permissions of the person using them. Anything an employee can reach, the assistant acting on their behalf can now find, summarise and repeat at speed, including the payroll file in a folder shared with everyone and the board paper left in a personal drive. That is not an argument against the technology; it is an argument for doing the data work before the rollout rather than after the first incident. In practice the readiness question is narrow and answerable: which sensitive stores are reachable by a wide audience, which of those are unlabelled, and what would an assistant surface today. We answer that before it becomes a board conversation.

What we do about it

Find it

  • Discovery across prioritised stores, confirmed at a scoping workshop
  • Classification and labelling of personal, financial, regulated and intellectual property
  • A data inventory and lineage view, from ingress to egress

Close it

  • Exposure and oversharing identified, then remediated as the work runs
  • Access realigned toward least privilege, not just reported on
  • Loss-prevention settings designed against how your people actually work

Keep it closed

  • Retention and disposal that executes, duplicates included
  • Ownership, accountability and the reporting rhythm that holds the gains
  • An operating model your team can run, or that we run with you

Remediation is part of the work, not the sequel

An assessment that ends as a report leaves you exactly where you started, with better vocabulary. Our engagements are built so remediation begins while findings are still landing: exposure closed, access realigned and redundant data queued for disposal, under a weekly rhythm of progress and risk. What you keep at the end is a reduced exposure and a prioritised plan for the rest, not a document.

Choosing tooling, without taking anyone's word for it

We are independent of any one platform, so here is the test we apply on your behalf, and which you should apply to us. Does it discover across cloud, on-premises, collaboration and messaging, structured and unstructured alike. Does it understand context well enough to tell a pay slip from a partnership agreement, without a rulebook of expressions to maintain and without drowning your team in false positives. Does it flag the things that actually cause incidents: unclassified and misclassified records, data sitting where it should not, permissions that are too broad, sharing that was never reviewed. Can it remediate permissions and sharing itself, or does every fix become a ticket. Does it work through your existing controls, including the labelling and loss-prevention tools you have already paid for, rather than asking you to replace them. And what does it need in your environment: agents and infrastructure, or an authorised connection. If a platform cannot answer those plainly in a demo on data like yours, that is the answer.

Three ways in

See it, measure it, or prove it

Demo

A working walkthrough against a scenario like yours, run by the engineer who would deploy it, not a sales team.

  • The capability shown end to end on realistic data
  • Your questions answered by the people who implement it
  • A plain view of what it would take to run in your environment
Book a demo

Data Risk Assessment

The size of the exposure, evidenced: what sensitive data you hold, who can reach it, and which controls do not hold.

  • Maturity rating against a recognised framework
  • Risk register with severity and likelihood
  • Policy and control gap assessment
  • Prioritised remediation plan
  • Board-ready summary of exposure
Request a Data Risk Assessment

Proof of value

Test the case before you scale it: one use case, one sponsor, a controlled environment and a fixed budget.

  • Working pilot in a controlled environment
  • Measured results against agreed success criteria
  • Data, risk and governance findings
  • Scale-up plan and cost estimate
  • A scale, adapt or stop recommendation
Start a proof of value
Proof

From data-risk findings to action in twelve weeks.

The company knew its data risks in outline but not in the specifics that let anyone act: sensitive information (personal, financial, intellectual property, and regulated data) spread across a large estate, exposure and oversharing unquantified, and retention practices leaving redundant data accumulating risk. Four priorities were clear (classify the sensitive, identify the exposure, realign the access, retire the redundant) and the brief was equally clear: findings that turn into action, not another assessment that ends as a report.

Read the engagement
Data security

Start with a conversation

Choose how you want to begin. A partner replies within one business day.

Common questions

Before you enquire

No. We are deliberately independent of any one product, and this page names none. Where tooling helps we bring what suits your estate, show it working on a scenario like yours in the demo, and leave you free to license it yourself, through us, or not at all.

No, it makes them work. Those tools enforce policy on data that has been found, understood and labelled; the common failure is not the enforcement layer but the classification beneath it. We improve what the estate knows about itself, then let your existing controls act on it.

A maturity rating against a recognised framework, a risk register with severity and likelihood, a policy and control gap assessment, a prioritised remediation plan, and a board-ready summary of exposure. It is scoped to evidence the size of the problem and to say what to fix first.

The proof of value tests one use case with one sponsor, in a controlled environment, on a fixed budget and timeframe. It ends in a measured result against criteria agreed up front and a recommendation to scale, adapt or stop. Use it when the case is plausible and you want evidence before committing to a rollout.

It is the right time, and the scope is narrower than a full program. We look at which sensitive stores are reachable by a wide audience, which of those are unlabelled, and what an assistant would surface today, then close the worst of it before the rollout rather than explaining it afterwards.

It helps, and we start from it rather than replacing it. The common finding is that the scheme is sound and its application is uneven: labels applied in some stores, ignored in others, and rarely tied to the access and retention behaviour they were meant to drive. That gap is what we measure and close.

The same senior people throughout. A partner stays accountable from the first conversation to the outcome, working alongside the engineers doing the remediation. Afterwards you can run the operating model yourself, or we can run it with you under a managed arrangement with agreed service levels and reporting.