What a data-protection regulator actually asks a security team to show

Compliance is not a document.

Most teams prepare for a regulator by writing a policy. The policy says the right things. Then the regulator asks a different question: not "what is your policy?" but "show me it happened."

That gap — between a stated control and evidence the control operated — is where audits get uncomfortable. A regulator is not testing your intentions. They are testing whether you can produce records, on request, that show a control worked on real data on a real day.

What they actually ask for.

Across frameworks, the questions rhyme. In plain terms, a regulator or auditor tends to ask a security team to show:

1. Data inventory. Where does personal data live, including the systems you did not officially sanction?
2. Access. Who can reach that data, on what basis, and who removed access when someone left?
3. Movement. Where does the data go — exports, third parties, AI tools — and what stops the wrong movement?
4. Incidents. When something went wrong, how did you detect it, and can you show the timeline?
5. Retention. How long is data kept, and can you prove records were not altered or deleted early?

Notice that each is a request for evidence, not for a promise.

Auditors do not grade your policy. They grade the distance between your policy and your logs.

Where teams get caught out.

The common failures are boringly consistent:

• The data inventory is a spreadsheet from last year, and the regulator asks about an app bought last month.
• Access records show who has access now, but not when it was granted or revoked.
• There is a detection story, but no way to reconstruct the sequence of an incident after the fact.
• Retention is a setting, not a proof — nobody can show a record was preserved unaltered.

Each gap is survivable in isolation. Together they turn a routine review into a scramble.

Build for evidence, not for the binder.

The shift that helps is to treat evidence as an output of your controls, produced continuously, rather than a report assembled in a panic. That means:

• An inventory that updates from real activity, so it is current when asked.
• Access and movement logged in a form you can query by person, data type, and date.
• Incident timelines that reconstruct themselves from correlated events.
• Retention that is demonstrably tamper-resistant.

If the evidence exists as a by-product of running the controls, the audit becomes a query, not a project.

How Cyfriq helps you demonstrate controls.

To be clear on the wording: Cyfriq does not make you compliant. It helps you demonstrate that your controls operated, and produces the evidence a reviewer asks for.

• Shadow-IT Discovery keeps the data-and-app inventory current from real usage, so the "where does data live" question has a live answer.
• Insider Threat Scoring and the Cross-signal Correlator reconstruct incident timelines from the underlying events.
• Data Loss Prevention records how personal data moved, including into AI tools, and what was blocked or redacted.
• WORM retention keeps records write-once and tamper-resistant, so preserved evidence can be shown to be unaltered.

Cyfriq is designed to align with the control expectations behind frameworks such as India's DPDP regime and sectoral rules, without claiming those frameworks certify the product. The value is in the evidence trail, and it stays yours.

For the inventory question specifically, The shadow-IT bill you're already paying is worth reading — unknown apps are the hardest part of "where does data live" to answer. You can also see our approach to data loss prevention.

Where to start.

Pick one likely question — "where does personal data live?" is a good one — and try to answer it with evidence today. The gaps you hit are your audit risk, mapped for free.

Read our trust page for how we handle evidence, or download the audit-readiness guide.

Book a demo and start a 14-day pilot. First findings arrive in 7 days, and you keep them either way.