gdpr — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited gdpr (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
A skill for producing draft GDPR/UK GDPR artefacts from a codebase. The outputs are starting points for a qualified person (DPO, privacy consultant, data protection lead) to review, not compliance determinations.
This skill produces drafts. It cannot determine lawful basis with certainty, cannot confirm whether a transfer mechanism is in place, cannot validate retention against business need, and cannot see contracts, DPAs, or the operational reality behind the code. Every output must be framed as a draft for human review, with confidence indicators on inferences.
Err toward over-flagging. A false positive wastes a few minutes of review. A false negative means a data flow goes unrecorded.
The user has asked for one or more of:
If the user mentions a specific subdirectory (e.g. "scan /api" or "just the backend"), treat that as the scope. Otherwise default to the whole repository, excluding standard directories (node_modules, .git, vendor, dist, build, .next, target, venv, __pycache__).
Five outputs by default, written to a gdpr-review/ directory at the repo root (or wherever the user specifies):
gdpr-review/summary.md - human-readable markdown report covering all findingsgdpr-review/ropa-draft.xlsx - structured draft ROPA aligned to the ICO controller template (green-shaded mandatory Article 30(1) columns, blue-shaded ICO-recommended useful additional columns). One row per identified processing activity, grouped by business function. Built from assets/ropa-template.xlsx.gdpr-review/transfer-register.csv - draft international transfer registergdpr-review/ai-processing.md - dedicated section for AI/LLM data processing findingsgdpr-review/methodology.md - what was scanned, what was excluded, what confidence the findings have, what was NOT checkedThe methodology file is critical. It tells the reviewer where to focus their attention and protects against the output being treated as definitive.
The ROPA is always XLSX. The green/blue colour coding mirrors the ICO original and carries practitioner meaning (green = legally mandatory, blue = ICO-recommended), which is lost in CSV. Do not produce a CSV version of the ROPA.
The skill scans across the following dimensions. The first four are the substantive findings the skill produces; dimensions 5-8 are cross-cutting overlays that affect lawful basis and rights analysis throughout.
Identify personal data the application processes. Look for:
Map detected fields to categories. Use the reference table in references/data-categories.md as the canonical taxonomy. Categories include identifiers (name, email, phone), location data, financial data, health data, biometric data, behavioural data, device data, communications content, special category data (Article 9), and criminal offence data (Article 10).
For each category found, capture:
users table, req.body.email in /api/signup)Identify every external service that personal data flows to. Scan:
Use the lookup table in references/processors.md to identify known processors, their typical role (controller/processor/joint controller), their data residency, and applicable transfer mechanisms. The table covers common ones: Stripe, Segment, Mixpanel, Amplitude, Sentry, PostHog, Google Analytics, Meta Pixel, Hotjar, Intercom, HubSpot, Mailchimp, SendGrid, Twilio, AWS, GCP, Azure, OpenAI, Anthropic, Cohere, Pinecone, Supabase, Auth0, Clerk, and similar.
If a service is found that is not in the lookup table, flag it as "UNKNOWN - reviewer to confirm" and note what data appears to be sent to it.
For each third party identified, determine likely transfer status:
Read references/transfer-mechanisms.md before populating the transfer register. The file explains why DPF status and the contractual fallback are recorded separately, how to set defaults that protect against a stale DPF list, when a Transfer Risk Assessment is required, and what the Confidence column measures under this schema.
Output to transfer-register.csv with columns: Service, Purpose, Data categories transferred, Destination country/region, DPF status (reviewer to verify), Contractual fallback if DPF not relied upon, TRA required if contractual fallback used, Confidence, Notes, Source files.
Always note that this is based on the default data residency of the provider. Many providers offer EU-only options that the codebase cannot see. Flag this in the methodology file.
This is a distinct dimension because the regulatory landscape is moving fast and the risks differ from typical SaaS. Scan for:
For each, flag:
Output to ai-processing.md with these findings, plus a "DPIA likely required if..." section calling out the patterns that would typically trigger Article 35.
Issues that don't fit the four dimensions above but matter:
/user/[email protected], ?email=...)PECR (Privacy and Electronic Communications Regulations 2003) sits over UK GDPR and frequently requires consent even where a UK GDPR lawful basis would otherwise support the processing. Read references/lawful-basis.md for the full PECR overlay guidance. The skill must flag:
In the ROPA, where PECR applies, the lawful basis cell should suggest the UK GDPR basis AND flag the PECR consent requirement. Where PECR consent is required and the codebase shows no consent management, flag this as a priority recommendation.
The ICO's statutory Age Appropriate Design Code applies to online services "likely to be accessed by children" in the UK, regardless of intended audience. The skill should flag AADC consideration whenever:
This is independent of Article 6 lawful basis and independent of Article 8 (parental consent under Consent basis). The skill should surface AADC in the methodology output and in the summary's recommendations, not bury it inside the children's-data flag.
Where any processing activity is suggested with Legitimate interests as its lawful basis, the skill must surface the Article 21 right-to-object obligation in the ROPA row (in the "Information rights process" column) and in the privacy notice starting points section of the summary.
Read references/scanning-strategy.md for the recommended approach. The high-level flow:
references/Do not try to read every file in a large repo. Be strategic: schema/migration files, API route handlers, form components, and config files give you 80% of the picture.
Every output file must contain, at the top:
DRAFT - FOR REVIEW BY A QUALIFIED PERSON
This document was generated by an automated scan of the codebase. It is a starting
point for human review, not a compliance determination. Findings may be incomplete
or incorrect. Lawful basis, transfer mechanisms, retention periods, and the
operational reality behind the code cannot be determined from code alone.
Generated: [ISO date]
Repository scanned: [path]
Scope: [whole repo / specific dirs]Use UK English in all output (organisation not organization, behaviour not behavior, etc.).
Confidence indicators on inferred fields use three levels: HIGH (the code makes it explicit), MEDIUM (strong contextual signal), LOW (best guess, flag for review).
The ROPA output is gdpr-review/ropa-draft.xlsx and mirrors the ICO's "Documentation for Controllers" template. Read references/ico-template.md for the full column structure, the mandatory vs useful-additional distinction, and worked examples before populating it.
Always start from assets/ropa-template.xlsx. It has the green/blue colour coding, the section headers (Mandatory under Article 30(1) / Useful additional information), the instructions sheet, the frozen panes, and the correct column widths. Open it with openpyxl, populate the rows, and save to gdpr-review/ropa-draft.xlsx.
The 16 green-shaded columns are required (Article 30(1) UK GDPR). The 9 blue-shaded columns are ICO-recommended but not legally required. Populate both. Where a value is genuinely unknown from code alone, write UNKNOWN - reviewer to confirm rather than leaving blank or guessing.
Do not produce a CSV version of the ROPA. The green/blue colour coding carries practitioner meaning (legally mandatory vs ICO-recommended) that does not survive CSV. The XLSX is the only ROPA output format.
Group rows by business function, then by purpose. Do not produce one row per API endpoint or per database table. A small consumer app typically results in 6-12 rows.
Common business functions for a SaaS or consumer app:
In summary.md, include a "Privacy notice starting points" section that lists, in plain English:
For each AI/LLM service detected, name the provider explicitly. The ICO's guidance on generative AI pushes controllers toward naming third party AI services in privacy notices rather than describing them as a generic "AI service". Use the following template for the AI processing bullet, filling in each placeholder from the findings in ai-processing.md and the transfer register:
We use [PROVIDER NAME] (a [REGION]-based AI service provider) to [DESCRIBE PURPOSE]. When we use this service, we send: [DATA CATEGORIES]. We do not send any data you submit to us [verify against actual data flow; amend if data subjects' submitted content is also sent]. [PROVIDER NAME] does not use the data we send to train its models [confirm against current provider terms]. The data is transferred to [COUNTRY]. We rely on [TRANSFER MECHANISM - confirmed by reviewer] for this transfer.
The bracketed cues are instructions to the drafter, not text to leave in the published privacy notice. Where the skill cannot determine the answer from code alone, write UNKNOWN - reviewer to confirm in the relevant placeholder rather than guessing.
This is NOT a privacy notice. It is raw material a drafter can use as a starting point, framed accordingly.
State these in methodology.md:
references/ico-template.md - the ICO ROPA column structure with mandatory vs useful-additional distinction. Read this before populating any ROPA output.references/data-categories.md - canonical taxonomy of personal data categories with detection patternsreferences/processors.md - lookup table of common third party services with role, residency, and transfer notesreferences/scanning-strategy.md - stack-specific scanning advice (Next.js, Django, Rails, etc.)references/lawful-basis.md - how to suggest a lawful basis with confidence indicators; covers PECR overlay and AADCreferences/transfer-mechanisms.md - how to record DPF status separately from the contractual fallback (UK Addendum to EU SCCs or UK IDTA), when a TRA is required, and what the Confidence column measures. Read this before populating the transfer register.references/personal-data-vs-business-contact.md - the distinction between personal data of natural persons and information about legal entities; how to split the analysis where both are presentassets/ropa-template.xlsx - empty ICO-aligned ROPA template (the only ROPA output format; green/blue colour-coded)assets/transfer-register-template.csv - empty transfer register templateRead references on demand. Do not load all of them upfront.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.