Docs / Reference
Frameworks
What each available framework asks, which parts Lintsure checks in code, and which need evidence outside code. Written in our own words; not legal advice.
This is the same knowledge the agents use. The Classifier uses it to suggest frameworks, the Officer to list outside-code items, and the MCP explain_framework tool to explain it. For the other frameworks on our roadmap, see the frameworks page.
EU AI Act
The EU's law on AI sorts AI uses by how much harm they could do. A few uses are banned. Uses that affect people's lives, like credit, hiring or education, are high-risk and need human oversight, logs, documentation and risk management. Chatbots and AI-made media need to be open about being AI. Most other AI only needs staff to understand the tools they use.
Applies to: Anyone who builds an AI system and offers it in the EU (a provider), and anyone who uses one in their work in the EU (a deployer), even if the company is based elsewhere.
Key dates
- 2025-02-02: Banned practices and the AI literacy duty start to apply.
- 2025-08-02: Rules for general-purpose AI model providers start to apply.
- 2026-08-02: General date of application, including most openness duties for chatbots and AI content.
- 2026-12-02: New bans on AI that makes non-consensual intimate images or child abuse material. Deadline for older generative systems to mark their output as AI-made.
- 2027-12-02: High-risk rules apply to uses listed in Annex III (credit, hiring, education and others). Moved later by the 2026 Digital Omnibus.
- 2028-08-02: High-risk rules apply to AI that is a safety part of products covered by Annex I (machinery, medical devices and others).
What it asks
| Ref | Obligation | Lintsure |
|---|---|---|
Art. 4 | AI literacy. Take steps so the people who build and use your AI understand it well enough for their role. Softened in 2026 from a strict duty to a duty to support. Evidence: A short training plan and who has done it. | Outside code |
Art. 5 | Banned practices. Some uses are not allowed at all, for example manipulating people in harmful ways, social scoring, reading emotions at work or school, and (from December 2026) making intimate images of real people without consent. Evidence: A written check that none of your features fall into a banned use. | Partly in codeai.emotion-or-biometric |
Art. 6 + Annex III | Is it high-risk?. AI used for things like credit, hiring, education, essential services or biometrics is high-risk unless it only does a narrow, preparatory task and doesn't really shape the outcome. Evidence: Your reasoning for the risk tier, written down. | Partly in codeai.automated-decision |
Art. 9 | Risk management. High-risk systems need a running process to find, test and reduce risks across the system's life. Evidence: A risk register for the AI system, reviewed over time. | Outside code |
Art. 10 | Data and data governance. Training and test data must fit the purpose, be checked for bias and gaps, and be handled with care. Evidence: A note on where the data came from and how it was checked. | Partly in code |
Art. 11 | Technical documentation. Keep a description of how the system works, what it's for, its limits and how it was tested. Evidence: Technical documentation following Annex IV. | Outside code |
Art. 12 | Record-keeping (logs). The system should automatically log what it did, so events can be traced later. | Checked in codeai.call-not-logged |
Art. 13 | Instructions for use. Give the people who deploy your system clear instructions: what it does, how well, its limits and how to oversee it. Evidence: Instructions for deployers. | Outside code |
Art. 14 | Human oversight. A person must be able to understand the output, ignore it, override it or stop the system. Evidence: The review or override step, and who uses it. | Partly in codeai.automated-decision |
Art. 15 | Accuracy, robustness, security. The system should perform as stated, cope with errors and resist attacks such as data poisoning or prompt injection. Evidence: Test results and the security measures in place. | Partly in codesecret.in-sourcesql.string-built |
Art. 17 | Quality management system. High-risk providers need a written quality system covering design, testing, changes and incidents. Smaller firms can keep it simpler. Evidence: The quality manual and its procedures. | Outside code |
Art. 26 | Duties when you use high-risk AI. If you use someone else's high-risk AI, follow its instructions, assign human oversight, watch how it works and keep its logs. Evidence: Named overseers and kept logs. | Outside code |
Art. 50(1) | Tell people they're talking to AI. If your AI talks with people, they must know it's an AI unless that's obvious. | Checked in codeai.hides-being-ai |
Art. 50(2) | Mark AI-made content. AI-generated images, audio, video and text should carry a machine-readable mark that they're AI-made. Evidence: How output is marked, for example C2PA metadata or watermarks. | Partly in codeai.synthetic-media |
Art. 50(4) | Label deepfakes. If you publish realistic fake media of people, places or events, say that it's AI-made. Evidence: The label shown to viewers. | Partly in codeai.synthetic-media |
Watch out
- The risk tier depends on the use, not the model. The same model can be low-risk in one feature and high-risk in another.
- Using a vendor's AI doesn't remove your duties. As a deployer you still have some.
- The 2026 Digital Omnibus moved high-risk dates later, but bans and openness duties still apply on their original or earlier dates.
- Code can show signals of risk. Only a person can decide the legal tier.
Checked on 2026-11-07.
GDPR
The EU's privacy law. If you handle data about people in the EU, you need a valid reason for each use, should collect only what you need, keep it safe, tell people what you do, and let them see, fix or delete their data. AI doesn't get special treatment: training on or feeding personal data into a model is still processing.
Applies to: Any organization that handles personal data while based in the EU, or that offers goods or services to people in the EU or tracks their behavior there.
What it asks
| Ref | Obligation | Lintsure |
|---|---|---|
Art. 5 | Core principles. Use data fairly and openly, only for clear purposes, collect the minimum, keep it accurate, don't keep it longer than needed, and keep it secure. Evidence: A retention schedule and a note on why each field is collected. | Partly in codepii.to-analyticspii.logged |
Art. 6 | A lawful reason. Every use of personal data needs one of six legal bases, such as consent, a contract, or legitimate interests weighed against people's rights. Evidence: The legal basis recorded for each processing purpose. | Outside code |
Art. 7 | Consent done right. If you rely on consent, it must be freely given, specific, informed and as easy to withdraw as to give. No pre-ticked boxes. Evidence: Consent records and the wording users saw. | Partly in code |
Art. 9 | Sensitive data. Health, biometric, ethnic, religious, political, sexual and union data is off-limits unless a specific exception applies. Evidence: The exception you rely on. | Partly in codeai.emotion-or-biometric |
Art. 12–15 | Transparency and access. Tell people clearly what you collect and why, and give them a copy of their data when they ask. Evidence: Your privacy notice and how access requests are handled. | Outside code |
Art. 17 | Right to erasure. When someone asks, and no exception applies, delete their data everywhere you hold it, including backups on rotation and third-party tools. Evidence: The deletion path and where it reaches. | Partly in code |
Art. 22 | Automated decisions. People have the right not to be subject to fully automated decisions with legal or similarly big effects, unless an exception applies and safeguards like human review are in place. Evidence: The human review step and how people can contest a decision. | Partly in codeai.automated-decision |
Art. 25 | Privacy by design and default. Build privacy in from the start, and make the most private setting the default. Evidence: Design notes showing privacy choices. | Partly in codepii.in-urlpii.to-analytics |
Art. 28 | Processors. Vendors that handle personal data for you need a contract with specific data protection terms. Evidence: Signed processing agreements with each vendor. | Partly in codepii.to-analytics |
Art. 30 | Records of processing. Keep a list of what personal data you process, why, with whom you share it and how long you keep it. Evidence: The register of processing activities. | Outside code |
Art. 32 | Security of processing. Protect personal data with security that fits the risk: encryption, access control, testing and the ability to recover. | Checked in codepii.loggedsecret.in-sourcetransport.plain-httptransport.tls-verify-offcrypto.weak-password-hashsql.string-builtpii.in-url |
Art. 33–34 | Breach notification. Tell the regulator within 72 hours of learning about a risky breach, and tell affected people when the risk to them is high. Evidence: A breach procedure and a breach log. | Outside code |
Art. 35 | Impact assessment (DPIA). Before risky processing, such as large-scale profiling or new AI uses on personal data, assess and reduce the risks. Evidence: A completed DPIA. | Outside code |
Art. 44–49 | Transfers outside the EU. Sending personal data outside the EU needs an approved route, such as an adequacy decision or standard contract clauses. Evidence: The transfer tool used for each non-EU vendor. | Partly in code |
Watch out
- Pseudonymised data, like hashed emails, is still personal data. Only truly anonymous data is out of scope.
- An AI model trained on personal data may itself hold personal data. Don't assume it's anonymous.
- Analytics and session-replay tools often collect more than you think. Check what each SDK sends.
- Legitimate interests is not a free pass. It needs a written balancing test.
Checked on 2026-11-07.
SOC 2
SOC 2 is not a law. It's a report from an independent CPA firm saying your controls for security (and optionally availability, confidentiality, processing integrity and privacy) are designed well, and in a Type II, that they worked over a period of months. Business customers ask for it before they trust you with their data.
Applies to: Any company that stores or processes customer data and sells to businesses, mostly in the US but also worldwide.
What it asks
| Ref | Obligation | Lintsure |
|---|---|---|
CC1 | Control environment. Leadership sets the tone: ethics, clear roles, hiring and training. Evidence: Org chart, code of conduct, background checks, training records. | Outside code |
CC2 | Communication. People inside and outside know their security duties and how to report problems. Evidence: Policies shared with staff and a way for customers to report issues. | Outside code |
CC3 | Risk assessment. You regularly look for risks to your goals, including fraud and changes, and decide how to handle them. Evidence: A yearly risk assessment. | Outside code |
CC4 | Monitoring of controls. You check that your controls keep working and fix gaps you find. Evidence: Internal reviews and how gaps were tracked. | Outside code |
CC5 | Control activities. You turn policies into concrete controls, including controls over technology. Evidence: Written policies mapped to controls. | Outside code |
CC6.1 | Logical access. Only the right people and systems can reach data. Secrets are protected, passwords are stored safely. | Checked in codesecret.in-sourcepii.loggedcrypto.weak-password-hashsession.cookie-insecurepii.in-url |
CC6.2–6.3 | Granting and removing access. Access is approved before it's given, reviewed regularly and removed quickly when people leave. Evidence: Access requests and quarterly access reviews. | Outside code |
CC6.6 | Boundary protection. Systems are protected from outside threats at their edges. | Checked in codecors.any-origin |
CC6.7 | Data in transit. Data moving between systems is protected, usually with properly verified TLS. | Checked in codetransport.plain-httptransport.tls-verify-off |
CC7.1 | Finding vulnerabilities. You look for weaknesses and misconfigurations and fix them. | Checked in codesql.string-built |
CC7.2–7.5 | Monitoring and incidents. You watch for unusual activity, respond to incidents and recover. Evidence: Logs, alerts and an incident response plan. | Partly in codeai.call-not-logged |
CC8.1 | Change management. Changes are reviewed, tested and approved before they reach production. Evidence: Pull request reviews and deploy records. | Partly in codeconfig.debug-on |
CC9 | Vendor and business risk. You manage risks from vendors and business disruption. Evidence: Vendor list with reviews, and a continuity plan. | Outside code |
P-series | Privacy criteria (optional). If privacy is in scope: notice, choice, collection limits, use, retention, disclosure and quality of personal data. Evidence: Privacy notice and data flow records. | Partly in codepii.to-analytics |
Watch out
- A SOC 2 report is about your controls, not a pass or fail certificate. Exceptions are normal and get described.
- Type I looks at one day. Type II covers a period, often 3 to 12 months, so start collecting evidence early.
- Using AI in your service can bring AI-specific risks into scope. Auditors may ask how you oversee it.
- The AICPA has proposed updated criteria. Check which version your auditor uses.
Checked on 2026-11-07.
ISO/IEC 27001
An international standard for running an information security management system: a repeatable way to find security risks, pick controls, and keep improving. You get certified by an accredited body after an audit. Annex A lists 93 controls in four groups: organizational, people, physical and technological. You choose which apply and explain why.
Applies to: Any organization that wants to prove to customers, often in Europe and Asia, that it manages information security in a structured way.
What it asks
| Ref | Obligation | Lintsure |
|---|---|---|
Clauses 4–10 | The management system. Define scope, get leadership commitment, assess and treat risks, set objectives, run internal audits and management reviews, and fix nonconformities. Amendment 1 adds that you consider climate change in your context. Evidence: Scope, risk assessment, Statement of Applicability, internal audit and management review records. | Outside code |
A.5 | Organizational controls (37). Policies, roles, asset inventory, supplier security, incident handling, legal duties and privacy. Evidence: Policies, supplier agreements and incident records. | Outside code |
A.5.34 | Privacy and protection of personal data. Meet the privacy laws and contracts that apply to personal data you hold. Evidence: Privacy compliance records. | Partly in codepii.to-analytics |
A.6 | People controls (8). Screening, terms of employment, awareness training, discipline and remote work. Evidence: Training and screening records. | Outside code |
A.7 | Physical controls (14). Protect offices, equipment and media. Often inherited from your cloud provider. Evidence: Cloud provider reports and office measures. | Outside code |
A.8.5 | Secure authentication. Log-in and sessions are built so they can't easily be stolen or bypassed. | Checked in codesession.cookie-insecure |
A.8.9 | Configuration management. Systems are set up securely and settings are controlled. | Checked in codeconfig.debug-on |
A.8.11 | Data masking. Hide or reduce sensitive data where full values aren't needed, such as in logs. | Checked in codepii.loggedpii.in-url |
A.8.15–8.16 | Logging and monitoring. Record important events, protect the logs and watch them for problems. Evidence: Log setup and alert rules. | Partly in codeai.call-not-logged |
A.8.20 | Network security. Networks and connections are protected and controlled. | Checked in codetransport.plain-httptransport.tls-verify-offcors.any-origin |
A.8.24 | Use of cryptography. Use strong cryptography correctly and manage keys safely, not in source code. | Checked in codesecret.in-sourcecrypto.weak-password-hash |
A.8.25–8.29 | Secure development. Build software securely: secure design, coding, testing and separation of environments. | Checked in codesql.string-built |
A.8.32 | Change management. Changes to systems are controlled and reviewed. Evidence: Change records. | Partly in code |
Watch out
- Certification is for the management system, not the product. Code findings feed into it but don't replace it.
- Your Statement of Applicability must explain every Annex A control you include or exclude.
- Certificates to the 2013 version expired in October 2025. Use the 2022 version.
Checked on 2026-11-07.
Lintsure is a readiness tool, not an audit or legal advice. Results cover code only; a qualified person should review them. Disclaimer