Compliance linting: checking code against GDPR, SOC 2 and the EU AI Act

Most teams already run a linter for style and bugs. Compliance linting uses the same approach for a different question: does this code do something a law or standard cares about? Things like writing personal data to logs, sending it to an analytics tool, or letting an AI make a decision about a person with no way for a human to step in.

This guide explains the idea, its limits, and how to use it.

Why compliance belongs in a linter at all

Compliance is mostly about process: policies, training, contracts, access reviews. But some requirements end up as specific lines of code, and those lines are written every day by developers and, more and more, by AI assistants. By the time someone notices, often during a customer’s security review, the pattern is in fifty places.

A linter is good at exactly this kind of problem: small, repeated, easy to miss, and cheap to fix when caught early.

Which requirements show up in code

Requirement	What it looks like in code
GDPR Art. 32, security of processing	Personal data in logs, data sent over plain HTTP, weak password hashing
GDPR Art. 5(1)(c), data minimisation	Emails and phone numbers sent to analytics or tracking tools
SOC 2 CC6.1 and ISO 27001 A.8.24	Secrets committed to source, weak cryptography, insecure session cookies
SOC 2 CC6.6 and CC6.7	APIs open to any website, TLS certificate checks turned off
SOC 2 CC7.1 and ISO 27001 A.8.28	SQL built from strings
EU AI Act Art. 12	AI calls with no record kept
EU AI Act Art. 14	Model output that becomes a final decision about a person with no review step
EU AI Act Art. 50	Prompts telling an AI to pose as a human, generated media with no marking

Each row is something a rule can look for, with a file and a line to point at.

What a compliance linter can and can’t tell you

It can tell you:

• where in the code a known risky pattern appears
• which controls that pattern relates to, so one fix can count for several frameworks
• what to change, and whether a finding is new since last time

It can’t tell you:

• whether a law applies to your company. That depends on your users, your data and your purpose, and needs a person.
• whether you are compliant. Most of every framework lives outside code.
• about data flows it can’t see, like a value passed through three functions in different files. Pattern-based rules miss some problems and flag some safe code.

A good compliance linter says these limits out loud, on every report. If a tool tells you your code “is compliant”, be suspicious.

The outside-code list matters as much as the findings

Because so much lives outside code, a useful report has two halves: what the code shows, and what still needs a person. For SOC 2 that second half includes access reviews, onboarding and offboarding, vendor checks and incident response. For the EU AI Act’s high-risk rules it includes risk management, technical documentation and a quality system. Seeing both halves in one place keeps a clean scan from being mistaken for being ready.

How it differs from a security scanner

There is overlap. SQL injection and leaked secrets are security problems and compliance problems at once. The differences are in the questions asked:

• A security scanner asks “can someone break in?” and often follows data deeply to find out.
• A compliance linter asks “what would a reviewer of this law or standard ask about?” and maps each answer to named controls. It also covers things that aren’t vulnerabilities at all, like an AI chatbot that doesn’t say it’s an AI.

Many teams will want both.

Adding it to your workflow

The same three places as any linter:

In the terminal:

npx lintsure scan

In CI, on every pull request:

- uses: lintsure/action@v1
  with:
    fail-on: gap

With a saved baseline, CI fails only on new findings, so an existing codebase isn’t blocked on day one.

Inside your coding agent:

claude mcp add lintsure -- npx -y @lintsure/mcp

Then ask: check this repo for compliance. Each finding comes back as a proposal (where, what, why and the benefit), and the agent is told to ask before changing anything.

Keeping decisions on record

Not every finding needs a fix. A public, read-only API that allows any origin may be fine. When a person decides that, the decision should be written down with a reason and a review date, not silently ignored. That record is useful later, when a reviewer asks why something looks the way it does.

Where to start

1. Run a scan and look at the findings by risk level.
2. Fix the quick, high-risk ones first: secrets, weak password hashing, personal data in logs.
3. Save a baseline, so new problems stand out.
4. Add it to CI.
5. Work through the outside-code list with whoever owns policies and processes.

Lintsure is the compliance linter we built for this. It’s open source, runs on your machine and never sends your code anywhere. Read what a linter is and why we named Lintsure after one, or browse the rules.