EU AI Act + CRA Dual Compliance: The Complete Developer Checklist for August 2026

Post #5 in the EU AI Act + CRA Dual Compliance Developer Series (5 posts)

This is the final post in the series. Posts 1 through 4 established who falls under both frameworks, mapped the cybersecurity requirements overlap between EU AI Act Art.15 and CRA Annex I, showed how to build a unified incident reporting pipeline for Art.73 and CRA Art.14, and designed a combined post-market monitoring stack for Art.72 and CRA Art.13. This post consolidates everything into a single actionable checklist.

Two deadlines now govern your compliance calendar. EU AI Act obligations for high-risk AI systems apply from 2 August 2026. CRA Art.14 reporting obligations follow on 11 September 2026. If you are building a high-risk AI system that also qualifies as a product with digital elements under the CRA — which most SaaS AI systems do — you have six weeks between those two deadlines where you are live on one regime before the second activates.

The checklist below is structured around five compliance domains. Each domain includes the specific obligations from both frameworks, a readiness test you can run today, and the artefacts you must produce before the deadline. Work through them in order — earlier sections create dependencies for later ones.

How to Use This Checklist

Each item has three states: DONE (artefact produced and documented), IN PROGRESS (work started), or NOT STARTED. Treat anything that is NOT STARTED on 1 July 2026 as a P0 item. The checklist is structured so that items in earlier sections produce outputs that later sections consume — skip the scope determination section and you will not know which subsequent items apply to your system.

For each domain we list both the EU AI Act obligation and the corresponding CRA obligation. Where the two frameworks impose identical requirements on the same technical system, we note the overlap and indicate that a single artefact satisfies both. Where they impose distinct, non-substitutable obligations, we list them separately.

Domain 1: Scope Determination

Before anything else, confirm whether your system falls under both frameworks. This is not a formality — the scope question determines the entirety of your compliance burden.

EU AI Act Scope (High-Risk Classification)

Checklist items:

• Annex III classification audit completed. Your system has been reviewed against all eight categories in EU AI Act Annex III (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, administration of justice). If your system falls in any category, it is presumptively high-risk. Document the classification decision with the specific Annex III entry it does or does not match.

• Art.6 assessment documented. EU AI Act Art.6 sets the general classification rule for high-risk AI systems. If your system is intended to be used as a safety component of a product already covered by Union harmonisation legislation listed in Annex I, you are high-risk regardless of the Annex III analysis. Check every product category in Annex I against your integration context.

• Prohibited practice exclusions confirmed. EU AI Act Art.5 lists prohibited AI practices. If any aspect of your system could fall within a prohibited category, this overrides the high-risk classification analysis — prohibition is not a compliance path, it is a prohibition. Document your Art.5 analysis.

• GPAI assessment documented. If your system is or incorporates a general-purpose AI model (GPAI), additional obligations under Art.50 apply. GPAI assessments are separate from the high-risk classification. Document whether your system is a GPAI provider, a high-risk system provider using a GPAI component, or both.

CRA Scope (Product with Digital Elements)

Checklist items:

• CRA Art.2 scope assessment completed. CRA Art.2 defines "products with digital elements" as any software or hardware product and its remote data processing solutions, where the product is able to connect either directly or indirectly to another device or network. Almost every SaaS AI system qualifies. Document whether your product is in scope and under which CRA Art.6 classification (default, important, or critical).

• CRA Art.7 important product determination documented. CRA Art.7 lists important products with digital elements in Annex II. If your product falls under Annex II, you face stricter conformity assessment requirements. AI systems used in critical infrastructure, healthcare, or industrial control systems often fall here.

• CRA Art.8 critical product determination documented. CRA Art.8 lists critical products in Annex III. Critical products require third-party conformity assessment regardless of other factors. Document your Art.8 status.

• Support period defined and documented. CRA Art.13 requires manufacturers to define the support period — the period during which security updates will be provided. This must be documented in the technical documentation and communicated to users. Define the support period now and document it.

Readiness test: Run grep -r "high-risk\|Annex III\|product with digital elements\|support period" ./docs/ — if these terms do not appear in your internal documentation, scope determination has not been completed.

Domain 2: Cybersecurity Requirements

Posts 2 in this series mapped Art.15 versus CRA Annex I in detail. This checklist summarises the implementation obligations.

EU AI Act Art.15 Requirements

EU AI Act Art.15 is titled "Accuracy, robustness and cybersecurity." It requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity throughout their lifecycle.

Checklist items:

• Accuracy metrics defined and tested. Art.15(1) requires high-risk AI systems to be designed and developed to achieve an appropriate level of accuracy. Define the accuracy metrics for your system and document the acceptable range. Run baseline accuracy tests and store results. This output feeds directly into your Art.11 technical documentation.

• Robustness specification documented. Art.15(2) requires systems to be resilient against errors, faults, and inconsistencies arising during use. Document your system's robustness requirements — what happens under partial failure of inputs, model components, or downstream integrations? Test each scenario and document results.

• Adversarial robustness assessment completed. Art.15(2) also requires resilience against attempts by third parties to alter use or performance through adversarial inputs. Conduct an adversarial ML assessment covering prompt injection (for LLM components), data poisoning (for trainable components), and model inversion/extraction attacks. Document findings and mitigations.

• Cybersecurity controls implemented. Art.15(3) specifies cybersecurity measures including access controls, confidentiality protections, resilience against denial-of-service attacks, and protection of training and validation data. Each of these has a corresponding CRA Annex I requirement. Implement the controls and document them in a format that satisfies both frameworks simultaneously.

• Continuous monitoring for accuracy degradation configured. Art.15 obligations are lifecycle obligations — they apply to the deployed system, not just at the point of conformity assessment. Configure automated monitoring for accuracy degradation and adversarial signal patterns. This output feeds the Art.72 post-market monitoring system.

CRA Annex I Requirements

CRA Annex I Part I specifies essential cybersecurity requirements. These are mandatory for all in-scope products.

Checklist items:

• Security-by-design assessment completed. CRA Annex I requires products to be delivered with no known exploitable vulnerabilities (at time of placing on market), default secure configurations, and minimal attack surface. Document a pre-release security assessment and any vulnerability findings.

• Authentication and access controls implemented and documented. CRA Annex I specifies authentication, authorisation, and access control requirements. Map your access control implementation against these requirements and document the mapping. Cross-reference with Art.15(3) controls — a single implementation document can satisfy both.

• Encryption requirements documented. CRA Annex I requires encryption of data at rest and in transit. Document your encryption implementation including key management procedures, cipher suite choices, and any exceptions with justification.

• Security update mechanism implemented. CRA Annex I requires a mechanism for distributing security updates to users. For SaaS systems this is typically automatic patching — document the patching process and the notification mechanism you use to inform deployers of security updates.

• SBOM generated and stored. CRA Annex I requires a Software Bill of Materials covering all components including third-party and open-source dependencies. Generate an SBOM in a machine-readable format (SPDX or CycloneDX). Store it in your EU-jurisdiction infrastructure — an SBOM stored on US-provider infrastructure is reachable under the CLOUD Act, creating a compliance evidence exposure problem.

• Vulnerability disclosure policy published. CRA Annex I requires a coordinated vulnerability disclosure policy. Publish the policy at a stable URL (typically /.well-known/security.txt) and register a contact channel for receiving external vulnerability reports.

Readiness test: Run a dependency audit today: npm audit --audit-level=high (or equivalent for your stack). If there are unfixed high-severity vulnerabilities, they will fail your CRA Annex I compliance assessment.

Domain 3: Technical Documentation

Both frameworks require comprehensive technical documentation. The good news: there is significant overlap, and a well-structured document set satisfies both simultaneously.

EU AI Act Art.11 Technical Documentation

EU AI Act Art.11 is titled "Technical documentation." Annex IV specifies the content requirements in detail.

Checklist items:

• Annex IV documentation structure completed. Annex IV lists nine required content areas for technical documentation of high-risk AI systems: general system description, detailed description including design and development (with training data methodology), monitoring/performance/testing information, computational resource requirements, pre-determined changes, third-party component dependencies, conformity assessment procedures applied, EU declaration of conformity, and post-market monitoring plan. Complete each section.

• Intended purpose statement documented. A precise intended purpose statement is the anchor for the entire Art.11 documentation — the accuracy requirements in Art.15 are assessed against it, the risk management system in Art.9 is built around it, and the conformity assessment evaluates whether the system achieves it. Write the intended purpose statement first.

• Training data methodology documented. Annex IV requires documentation of training, validation, and testing datasets and the methodology for their selection. This includes data sources, relevance to the intended purpose, data governance procedures, and bias assessment. This section also satisfies EU AI Act Art.10 (data and data governance) requirements.

• Logs and record-keeping configured. EU AI Act Art.12 (record-keeping) requires that high-risk AI systems be designed to enable automatic logging of events. EU AI Act Art.19 specifies the requirements for automatically generated logs. Configure your system to generate audit-compliant logs covering prediction inputs, outputs, operator interventions, and system performance metrics.

• Art.17 quality management system documented. EU AI Act Art.17 requires providers to implement a quality management system. The QMS must cover testing and validation procedures, corrective and preventive action procedures, and post-market monitoring integration. Document the QMS procedures. This does not require a separate ISO 9001 certification, but it must be a documented, implemented, and auditable system.

CRA Art.31 Technical Documentation

CRA Art.31 specifies technical documentation requirements for products with digital elements.

Checklist items:

• CRA technical documentation package assembled. CRA Art.31 requires technical documentation covering the general description of the product and its intended use, the design and development documentation, the assessment of the cybersecurity risks, the essential requirements in Annex I and how they are addressed, and the list of harmonised standards applied. Assemble this package and cross-reference it with your AI Act Art.11 documentation — most sections overlap and a single document can serve both.

• EU declaration of conformity prepared. CRA Art.28 requires a written EU declaration of conformity attesting compliance with the regulation. Prepare the declaration template, specifying the regulation, the product, the conformity assessment procedure used, and the manufacturer's identity. Equivalent is required under EU AI Act Art.47. A single declaration covering both regulations is legally valid if structured correctly.

• Support period and update commitment documented in user-facing materials. CRA Art.13 requires that the defined support period and update commitment be clearly communicated to users, including in technical documentation. Add this information to your product documentation and ensure it is accessible to deployers before they place the product in service.

Readiness test: Count the sections in your existing technical documentation against the Annex IV and CRA Art.31 checklists. Any section that exists in the checklist but not in your documentation is a gap. The most commonly missing sections are: adversarial robustness testing methodology, training data bias assessment, and explicit post-market monitoring plan description.

Domain 4: Incident Reporting Readiness

Post 3 in this series designed the unified incident reporting pipeline. This checklist validates that the pipeline is operational before the August 2026 deadline.

EU AI Act Art.73 Serious Incident Reporting

EU AI Act Art.73 is titled "Reporting of serious incidents."

Checklist items:

• Serious incident definition operationalised. Art.73 defines serious incidents as events causing or likely to cause death, serious injury, disruption to critical infrastructure, fundamental rights violations, or property damage. Convert this legal definition into operational detection criteria — what signals in your monitoring system indicate that a serious incident may have occurred?

• Art.73 reporting timeline pipeline configured. Serious incidents must be reported to the market surveillance authority of the Member State where the incident occurred. The timeline under Art.73 is: 15 days for serious incidents causing harm, 2 days for serious incidents involving a risk to safety or fundamental rights of persons. Configure automated alerting with clock-start timestamps.

• Regulatory contact list current. Identify the national market surveillance authorities for each EU Member State where your system is deployed. Maintain a current contact list. Most Member States have designated their existing product safety authorities; check each country's implementing regulation.

• Incident classification logic documented. Document explicitly how your system distinguishes between a serious incident (Art.73 triggering) and a non-serious performance defect (Art.20 corrective action triggering). Regulators will ask this question during any audit.

CRA Art.14 Reporting Obligations

CRA Art.14 is titled "Reporting obligations of manufacturers."

Checklist items:

• ENISA early warning mechanism configured. CRA Art.14 requires notification of ENISA and the relevant national CSIRT (Computer Security Incident Response Team) within 24 hours of becoming aware of an actively exploited vulnerability or a significant-impact security incident. Configure your monitoring to produce an ENISA-format early warning notification within 24 hours of a confirmed awareness event.

• 72-hour intermediate notification process documented. Art.14 requires an intermediate notification within 72 hours, providing additional detail on the nature of the vulnerability and the affected products. Define the team and process responsible for producing this notification.

• 14-day final report process documented. Art.14 requires a final vulnerability notification within 14 days of the early warning, including a complete description of the vulnerability, the products affected, severity, and remediation measures. Assign ownership of this artefact.

• "Awareness" event definition documented. The Art.14 clock starts when the manufacturer "becomes aware." Define exactly what constitutes awareness in your system — specifically, what monitoring alert state or human review action constitutes the awareness event. Document this definition in your incident response runbook. This is the artefact regulators will examine when auditing your reporting timeline compliance.

• CSIRT contacts current. Identify the national CSIRT for each Member State where your product is placed on the market. ENISA maintains a directory. Verify the contact information before 2 August 2026.

Readiness test: Conduct a tabletop incident simulation. Pick a hypothetical scenario: an adversarial input causes your AI system to produce harmful outputs that trace to an exploitable vulnerability in a model component. Walk through which Art.73 and Art.14 obligations trigger, who is responsible for each notification, what the clock start times are, and what artefacts must be produced. Identify any process gaps.

Domain 5: Post-Market Monitoring

Post 4 in this series designed the combined post-market monitoring stack. This checklist validates it before go-live.

EU AI Act Art.72 Post-Market Monitoring Plan

EU AI Act Art.72 is titled "Post-market monitoring by providers and post-market monitoring plan."

Checklist items:

• Post-market monitoring plan written. Art.72 requires a documented post-market monitoring plan as part of the Art.11 technical documentation. The plan must specify what data is collected, at what frequency, by whom, and how it is analysed. The plan must be proportionate to the risk profile of the system and the volume of deployment.

• Performance metric baselines established. Define the baseline performance metrics against which drift is measured. These must match the metrics stated in the Art.11 technical documentation's intended purpose section. Establish acceptable ranges and the threshold at which a performance deviation triggers an internal escalation.

• Harm signal collection pipeline operational. Art.72 requires collection of data from deployers and, where applicable, users, to detect need for corrective actions under Art.20. Implement the feedback pipeline — whether through API callbacks, periodic reports from deployers, or in-product feedback mechanisms — before August 2026.

• Corrective action trigger documented. Document the specific conditions that trigger an Art.20 corrective action review. The corrective action track connects directly to the Art.73 serious incident reporting pipeline — a corrective action that results from a performance defect that caused harm is a potential Art.73 trigger. The two processes must be connected.

CRA Art.13 Post-Market Security Monitoring

CRA Art.13 is titled "Obligations of manufacturers." Section 5 contains the post-market monitoring requirement.

Checklist items:

• Vulnerability handling process operational. CRA Art.13 requires an ongoing vulnerability handling process. This is not a one-time assessment — it must be a continuously running process that receives vulnerability reports, triages them, tracks remediation, and closes the loop with the reporter. Implement using a ticketing system, assign clear SLA targets, and document the process in your quality management system.

• SBOM scanning pipeline operational. CRA Art.13 requires monitoring for vulnerabilities in third-party components. Implement automated SBOM scanning against the National Vulnerability Database (NVD) or equivalent. Configure the scan to run on each deployment and on a scheduled basis for running production systems.

• Security update distribution pipeline tested end-to-end. Test that your security update distribution mechanism works correctly — that updates are pushed to all affected deployments, that deployers are notified, and that a confirmation mechanism exists. For SaaS systems, this typically means testing your automated deployment pipeline under a production-equivalent load.

• SBOM update process in place. CRA requires that the SBOM be maintained as the product changes. Automate SBOM regeneration as part of every CI/CD pipeline run and store the updated SBOM with each release artefact.

Readiness test: Check when your SBOM was last generated. If it predates any dependency update, your SBOM is stale and your CRA Art.13 continuous monitoring obligation is unmet.

Timeline: What Is Live When

Understanding the two-deadline structure prevents compliance calendar errors.

2 August 2026 — EU AI Act high-risk obligations live:

• Art.9 (risk management system) — must be implemented and documented
• Art.10 (data and data governance) — training data documentation complete
• Art.11 (technical documentation) — Annex IV documentation package complete
• Art.13 (transparency) — deployer documentation and instructions complete
• Art.15 (accuracy, robustness, cybersecurity) — all controls implemented and tested
• Art.17 (quality management system) — QMS documented and operational
• Art.72 (post-market monitoring) — monitoring plan implemented and collecting data
• Art.73 (serious incident reporting) — reporting pipeline operational, contacts current
• Art.47 (EU declaration of conformity) — declaration prepared (signing triggered by conformity assessment completion)

11 September 2026 — CRA Art.14 reporting obligations live:

• CRA Art.14 24-hour ENISA early warning pipeline — operational
• CRA Art.14 72-hour intermediate notification process — documented and assigned
• CRA Art.14 14-day final report process — documented and assigned

Ongoing from CRA entry into force:

• CRA Art.13 vulnerability handling — continuous process, no specific deadline
• CRA Annex I cybersecurity requirements — must be met at time of placing on market or deploying
• CRA Art.31 technical documentation — complete before placing on market

Six-week overlap (2 August – 11 September 2026): During this period, your AI Act Art.73 incident reporting pipeline is live but your CRA Art.14 reporting pipeline is not yet legally required. However, the technical infrastructure for both is shared. Build them together and deploy them together on 2 August — the six-week head start is an operational advantage, not a reason to defer.

Infrastructure Considerations for Dual Compliance

Both frameworks impose obligations that have a hosting-jurisdiction component that SaaS developers often underestimate.

Compliance evidence residency. Your technical documentation, SBOM, monitoring logs, and incident records constitute compliance evidence that regulators may demand access to. If this evidence is stored on US-provider infrastructure, it is potentially reachable under the US CLOUD Act, which can compel disclosure to US government authorities regardless of the data's physical location. For EU-regulated products, compliance evidence should reside on infrastructure outside US jurisdiction — meaning providers where the ultimate parent company is not incorporated under US law.

AI Act Art.12 and Art.19 logs. The record-keeping and automatic logging obligations require specific log retention periods. Art.12 requires logs to be retained for a period appropriate to the intended purpose, taking into account the applicable legal obligations. Logs stored on US cloud infrastructure are CLOUD Act-exposed. Logs stored on EU-native infrastructure (hosted on providers without US parent companies) are not.

CRA SBOM storage. An SBOM stored on AWS, Azure (Microsoft), or Google Cloud is reachable under the CLOUD Act. An adversary who obtains your SBOM via a compelled US disclosure knows every vulnerability in your product. Store SBOMs on EU-native infrastructure.

Incident notification pipeline latency. CRA Art.14's 24-hour clock for ENISA notification is tight. Any monitoring infrastructure that runs on US-east-coast servers, routes through US traffic exchange points, or relies on US-incorporated security vendors adds jurisdictional risk to the notification pipeline. EU-native infrastructure typically offers better latency to EU regulatory endpoints.

Final Verification Before August 2026

Run this verification pass in July 2026:

Technical documentation review: Is every Annex IV section complete? Is every CRA Art.31 section complete? Are the two documentation packages cross-referenced?

Cybersecurity controls test: Has every Art.15 control been tested against its stated requirement? Has every CRA Annex I requirement been mapped to a specific control implementation with evidence?

Incident reporting drill: Run the tabletop simulation from Domain 4. Did every notification reach the right destination within the required time? Were all required artefacts produced?

Post-market monitoring verification: Is the Art.72 monitoring plan collecting data from live deployers? Is the CRA Art.13 vulnerability scanning pipeline running? Is the SBOM current?

Infrastructure audit: Is your compliance evidence, logs, SBOM, and monitoring data stored on EU-native infrastructure? Is any critical compliance pipeline component hosted by a US-parent-company provider?

Series Summary

This five-post series has covered the EU AI Act + CRA dual compliance landscape for SaaS developers:

Post 1 established who falls under both frameworks and why the SaaS AI market segment faces dual-regulation at scale.

Post 2 mapped Art.15 cybersecurity requirements against CRA Annex I essential requirements, showing where a single implementation satisfies both and where distinct obligations remain.

Post 3 designed the unified incident reporting pipeline for Art.73 and CRA Art.14, with explicit clock-start definitions and notification artefact specifications.

Post 4 architected the combined post-market monitoring stack for Art.72 and CRA Art.13, showing how one technical infrastructure serves both continuous monitoring obligations.

Post 5 (this post) assembled the complete pre-August-2026 developer checklist across all five compliance domains.

The August 2026 deadline is 54 days away. Scope determination and technical documentation are the longest-lead items — both require decisions and reviews that cannot be completed in the final week before the deadline. Start there.

sota.io runs on EU-native infrastructure (Hetzner Germany) with no US parent company and no CLOUD Act exposure. Every compliance artefact, log, and SBOM you store on sota.io is outside US jurisdiction by default — relevant for teams implementing the infrastructure requirements above. See how sota.io handles AI Act + CRA compliance obligations for hosted applications.