GDPR, DPDP, SOC 2 — the minimum scan you need before an audit.

A control-mapped checklist of what an external security scan can evidence for GDPR, India's DPDP Act, and SOC 2, and what it cannot. Run it before the auditor does.

Compliance frameworks are mostly about process: who approves access, how incidents are handled, where the policy lives. An external scan cannot evidence any of that. What it can do is answer the handful of questions every auditor asks about your public surface, before the auditor does, and produce the kind of artefact that makes the rest of the audit shorter.

This is the control-mapped checklist we run for customers heading into a GDPR review, a DPDP readiness assessment, or a SOC 2 Type I or Type II. It is deliberately minimal. Nothing here replaces counsel or a qualified auditor, and this post is not legal advice.

What can an external scan prove, and what can it not?

Be clear with yourself about the boundary. A scan of your public surface can show, with evidence and a timestamp, how your systems behave from the outside. It cannot show that a policy exists, that staff were trained, or that access reviews happened. Use it for the technical controls where external behaviour is the control, and keep a separate evidence trail for everything else.

GDPR: what does the surface say about your data handling?

The regulation is about processing, but a surprising amount of it is visible from a browser.

• Consent before non-essential cookies. The scanner loads the site cold, records every cookie and third-party request fired before any interaction, and flags analytics or advertising tags that run before consent.
• A reachable privacy notice. Presence, link from every page footer, and whether it names a controller and a contact route, as Article 13 requires.
• Third-party and sub-processor discovery. Every external domain the site contacts, grouped by purpose, so your Article 28 processor list and your actual traffic can be reconciled.
• No personal data in the clear. Exposed exports, directory listings, verbose error pages, and public buckets are breach-notification events waiting to happen under the 72-hour rule in Article 33. These are Critical by impact regardless of how they were found.
• Transport security. TLS configuration, HSTS, and mixed content. Weak transport is the most common technical-measures finding under Article 32.

DPDP: what does India's Digital Personal Data Protection Act expect?

DPDP is newer, and the technical expectations overlap heavily with GDPR. The specific items we look for, with a fuller treatment in our DPDP compliance checklist for websites:

• Notice and consent. A clear notice at or before collection, with consent that is affirmative rather than pre-ticked. Same cookie-behaviour check as above, plus form-level checks on sign-up flows.
• Grievance contact. A published route to a grievance officer or equivalent, reachable from the privacy notice.
• Data exposure. Identical to the GDPR items: nothing personal reachable without authorisation.
• Security safeguards. Transport security and the absence of the exposure classes above, which is the practical reading of the reasonable-safeguards requirement for an external review.

SOC 2: which criteria can an external scan evidence?

SOC 2 auditors want evidence that controls operated over a period. A scan that runs on a schedule and keeps history is a control operating. The criteria an external scan speaks to most directly:

• Vulnerability management. Dated scan reports showing findings, their severity, and their closure over time. A Type II wants the series, not a single snapshot.
• Change management. Surface diffs between scans show what appeared, what changed, and when, which corroborates your change log from the outside.
• Logical access. Nothing administrative reachable without authentication. Verified, not inferred, before it is reported.
• Encryption in transit. TLS, HSTS, and certificate hygiene across every host, not just the primary domain.
• Monitoring. Scheduled scans with alerts on new findings are themselves a monitoring control. Keep the alert history.

What is the minimum pre-audit checklist?

If you only do one scan before the audit, make sure it covers all of this:

1. Enumerate every public host, including subdomains and stale environments. The audit scope is what exists, not what you remember deploying.
2. Check transport security on all of them.
3. Record cookie and third-party behaviour before consent.
4. Confirm the privacy notice and contact routes are reachable.
5. Look for exposed personal data: buckets, exports, listings, verbose errors.
6. Confirm nothing administrative is reachable unauthenticated.
7. Export the report with the date, the scope, and the evidence attached.
8. Schedule it to run again, so the next audit has a history instead of a snapshot.

How do you turn a scan into audit evidence?

Auditors need three things from any artefact: what was tested, when, and what the result was. Every Pythorix report carries the scan scope, the timestamp, the finding list with severities and evidence, and the control mapping for the frameworks you enabled. The PDF goes in the evidence folder; the JSON goes to whoever maintains the compliance platform.

Run it before the kickoff, fix what you can, and run it again. Walking into the first meeting with a dated report, a list of what was closed, and a scheduled scan already running changes the tone of the entire engagement.