{"id":1366,"date":"2026-02-10T22:54:09","date_gmt":"2026-02-10T21:54:09","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/dora-article-28-evidence-pack-2\/"},"modified":"2026-03-26T00:20:10","modified_gmt":"2026-03-25T23:20:10","slug":"dora-article-28-evidence-pack","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dora-article-28-evidence-pack\/","title":{"rendered":"DORA Article 28 \u2014 Pack de preuves"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Introduction<\/h2>\n\n\n\n<p>DORA Article 28 exige des entit\u00e9s financi\u00e8res r\u00e9glement\u00e9es qu&rsquo;elles d\u00e9montrent un contr\u00f4le efficace des <strong>risques tiers ICT<\/strong>.<\/p>\n\n\n\n<p>Cette obligation va bien au-del\u00e0 des questionnaires fournisseurs ou des d\u00e9clarations contractuelles. Les auditeurs n&rsquo;\u00e9valuent pas l&rsquo;intention \u2014 ils \u00e9valuent les <strong>preuves<\/strong>.<\/p>\n\n\n\n<p>Cet article fournit un pack de preuves pratique pour DORA Article 28, se concentrant sur ce que les auditeurs demandent g\u00e9n\u00e9ralement, d&rsquo;o\u00f9 les preuves doivent provenir, et comment les syst\u00e8mes CI\/CD et de livraison cloud doivent soutenir la gestion des risques tiers ICT.<\/p>\n\n\n\n<p>Il comble l&rsquo;\u00e9cart entre deux perspectives compl\u00e9mentaires :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Les auditeurs<\/strong> pensent en termes d&rsquo;<em>objectifs de contr\u00f4le, de preuves et de responsabilit\u00e9<\/em>.<\/li>\n\n\n\n<li><strong>Les ing\u00e9nieurs<\/strong> pensent en termes de <em>syst\u00e8mes, pipelines, configurations et automatisation<\/em>.<\/li>\n<\/ul>\n\n\n\n<p>Les deux vues sont valides \u2014 mais elles ne sont <strong>pas interchangeables<\/strong>. Cet article montre ce que les auditeurs cherchent r\u00e9ellement \u00e0 v\u00e9rifier, comment les ing\u00e9nieurs doivent impl\u00e9menter les contr\u00f4les pour satisfaire ces attentes, et o\u00f9 les malentendus surviennent g\u00e9n\u00e9ralement.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Ce que les audits Article 28 v\u00e9rifient r\u00e9ellement<\/h2>\n\n\n\n<p>Du point de vue de l&rsquo;audit, l&rsquo;Article 28 r\u00e9pond \u00e0 quatre questions fondamentales :<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Savez-vous de quels tiers ICT vous d\u00e9pendez ?<\/strong><\/li>\n\n\n\n<li><strong>Les obligations contractuelles sont-elles applicables en pratique ?<\/strong><\/li>\n\n\n\n<li><strong>Pouvez-vous surveiller continuellement les risques tiers ?<\/strong><\/li>\n\n\n\n<li><strong>Pouvez-vous sortir en toute s\u00e9curit\u00e9 si un fournisseur d\u00e9faille ou devient non conforme ?<\/strong><\/li>\n<\/ol>\n\n\n\n<p>Les preuves doivent \u00eatre <strong>op\u00e9rationnelles<\/strong>, <strong>tra\u00e7ables<\/strong> et <strong>v\u00e9rifiables<\/strong> \u2014 pas uniquement documentaires.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comment les auditeurs abordent une revue Article 28<\/h3>\n\n\n\n<p>Les auditeurs ne commencent pas par les outils ou les diagrammes d&rsquo;architecture. Ils commencent par des <strong>questions de risque<\/strong> :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Les fournisseurs ICT tiers introduisent-ils un risque op\u00e9rationnel non g\u00e9r\u00e9 ?<\/li>\n\n\n\n<li>Les contr\u00f4les sont-ils applicables au-del\u00e0 des syst\u00e8mes internes ?<\/li>\n\n\n\n<li>L&rsquo;organisation peut-elle d\u00e9montrer une supervision continue ?<\/li>\n\n\n\n<li>Les preuves sont-elles objectives et temporellement born\u00e9es ?<\/li>\n<\/ul>\n\n\n\n<p>Les preuves sont \u00e9valu\u00e9es comme <strong>preuve de contr\u00f4le op\u00e9rationnel<\/strong>, pas comme confirmation de politique.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Perspective<\/th><th>Focus<\/th><\/tr><\/thead><tbody><tr><td><strong>Vue auditeur<\/strong><\/td><td>Cette organisation peut-elle d\u00e9montrer un contr\u00f4le efficace du risque tiers ICT ?<\/td><\/tr><tr><td><strong>Vue ing\u00e9nieur<\/strong><\/td><td>Comment appliquer et g\u00e9n\u00e9rer des preuves via les syst\u00e8mes CI\/CD et cloud ?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Vue d&rsquo;ensemble du pack de preuves<\/h2>\n\n\n\n<p>Un pack de preuves DORA Article 28 couvre g\u00e9n\u00e9ralement <strong>cinq domaines de preuves<\/strong> :<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Inventaire des fournisseurs et criticit\u00e9<\/li>\n\n\n\n<li>Contr\u00f4les contractuels et droits d&rsquo;audit<\/li>\n\n\n\n<li>Application des contr\u00f4les CI\/CD et cloud<\/li>\n\n\n\n<li>Preuves de surveillance et d&rsquo;incidents<\/li>\n\n\n\n<li>Preuves de strat\u00e9gie de sortie et de r\u00e9silience<\/li>\n<\/ol>\n\n\n\n<p>Each domain below explains what auditors expect, what evidence to show, and where it should come from \u2014 from both the <strong>Vue auditeur<\/strong> and the <strong>Vue ing\u00e9nieur<\/strong>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Supplier Inventory &amp; Criticality<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What auditors expect<\/h3>\n\n\n\n<p>Auditors want proof that you have:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>identified <strong>all ICT third-party providers<\/strong>,<\/li>\n\n\n\n<li>classified them by <strong>criticality<\/strong>,<\/li>\n\n\n\n<li>linked them to <strong>business services and delivery pipelines<\/strong>.<\/li>\n<\/ul>\n\n\n\n<p>They expect inclusion of CI\/CD SaaS platforms (not just traditional vendors), visibility into cloud services, registries, and code hosting, and linkage between suppliers and actual systems in use.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Evidence to provide<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Centralized <strong>ICT supplier inventory<\/strong><\/li>\n\n\n\n<li>Criticality classification (critical \/ important \/ non-critical)<\/li>\n\n\n\n<li>Mapping between suppliers, CI\/CD tooling, and cloud runtime components<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical evidence artifacts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Supplier inventory register (exportable)<\/li>\n\n\n\n<li>Risk classification methodology<\/li>\n\n\n\n<li>Mapping table: <em>Supplier \u2192 CI\/CD \/ Cloud component<\/em><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Auditor View<\/h3>\n\n\n\n<p>Auditors ask:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do you have a <strong>complete inventory<\/strong> of ICT third-party providers?<\/li>\n\n\n\n<li>Are providers <strong>classified by criticality<\/strong>?<\/li>\n\n\n\n<li>Is this classification tied to <strong>business services and delivery systems<\/strong>?<\/li>\n<\/ul>\n\n\n\n<p>What they verify: inventory completeness, consistency with actual systems in use, and traceability to risk management decisions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Engineer View<\/h3>\n\n\n\n<p>Engineers must ensure:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CI\/CD platforms, Git hosting, registries, runners, cloud services are <strong>explicitly registered as suppliers<\/strong>,<\/li>\n\n\n\n<li>supplier metadata (criticality, owner, usage) is <strong>kept in sync<\/strong> with real usage,<\/li>\n\n\n\n<li>pipelines reference approved suppliers only.<\/li>\n<\/ul>\n\n\n\n<p>Typical implementation:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CMDB or supplier registry linked to CI\/CD tooling,<\/li>\n\n\n\n<li>automated checks preventing unapproved services,<\/li>\n\n\n\n<li>documentation generated from live configurations.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">2. Contr\u00f4les contractuels et droits d&rsquo;audit<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What auditors expect<\/h3>\n\n\n\n<p>Contracts must <strong>enable control<\/strong>, not just describe it. Auditors look for enforceable clauses covering:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>audit rights,<\/li>\n\n\n\n<li>incident notification timelines,<\/li>\n\n\n\n<li>evidence retention,<\/li>\n\n\n\n<li>subcontractor transparency,<\/li>\n\n\n\n<li>exit and transition obligations.<\/li>\n<\/ul>\n\n\n\n<p>More importantly, they verify that these clauses are <strong>operationally enforceable<\/strong>.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><em>\u00ab\u00a0You have audit rights in the contract \u2014 how do you exercise them in practice?\u00a0\u00bb<\/em><\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Evidence to provide<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Contract excerpts showing audit rights, monitoring access, and incident notification clauses<\/li>\n\n\n\n<li>Proof contracts apply to <strong>actual providers in use<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical evidence artifacts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Contract clause extracts<\/li>\n\n\n\n<li>Supplier contract register<\/li>\n\n\n\n<li>Legal review notes linking clauses to Article 28 requirements<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Auditor View<\/h3>\n\n\n\n<p>Auditors look for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>enforceable <strong>audit rights<\/strong>,<\/li>\n\n\n\n<li><strong>incident notification obligations<\/strong>,<\/li>\n\n\n\n<li>evidence retention commitments,<\/li>\n\n\n\n<li>visibility over <strong>subprocessors<\/strong>,<\/li>\n\n\n\n<li>defined <strong>exit clauses<\/strong>.<\/li>\n<\/ul>\n\n\n\n<p>They do <em>not<\/em> assume contracts are effective just because they exist.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Engineer View<\/h3>\n\n\n\n<p>Engineers must:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>know which contractual obligations impact technical controls,<\/li>\n\n\n\n<li>ensure platforms can actually <strong>produce the required evidence<\/strong>,<\/li>\n\n\n\n<li>support audits without ad-hoc data collection.<\/li>\n<\/ul>\n\n\n\n<p>Typical implementation:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>mapping contract clauses \u2192 technical controls,<\/li>\n\n\n\n<li>ensuring logs, SBOMs, approvals are retained long enough,<\/li>\n\n\n\n<li>making audit access technically possible (read-only, scoped).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">3. CI\/CD &amp; Cloud Control Enforcement<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What auditors expect<\/h3>\n\n\n\n<p>Auditors verify that third-party tooling is <strong>controlled in practice<\/strong>, not trusted blindly. This includes source code hosting platforms, CI\/CD orchestration services, runners and execution environments, and artifact registries and dependency ecosystems.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Evidence to provide<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Access control configuration (IAM, roles, SoD)<\/li>\n\n\n\n<li>Branch protection and approval rules<\/li>\n\n\n\n<li>Build isolation and runner governance<\/li>\n\n\n\n<li>Artifact integrity (SBOM, signing)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical evidence artifacts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CI\/CD platform configuration screenshots or exports<\/li>\n\n\n\n<li>Pipeline policy definitions (Policy as Code)<\/li>\n\n\n\n<li>SBOM and artifact signing reports<\/li>\n\n\n\n<li>Access logs from Git \/ CI\/CD platforms<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Auditor View<\/h3>\n\n\n\n<p>Auditors want proof that:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>access is controlled and segregated,<\/li>\n\n\n\n<li>approvals are enforced,<\/li>\n\n\n\n<li>artifacts are protected against tampering,<\/li>\n\n\n\n<li>third-party tooling does not bypass internal controls.<\/li>\n<\/ul>\n\n\n\n<p>They test whether controls are <strong>systematic<\/strong>, not manual.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Engineer View<\/h3>\n\n\n\n<p>Engineers implement:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM, role separation, branch protections,<\/li>\n\n\n\n<li>pipeline approvals and policy gates,<\/li>\n\n\n\n<li>SBOM generation and artifact signing,<\/li>\n\n\n\n<li>runner isolation and token scoping.<\/li>\n<\/ul>\n\n\n\n<p>Key mindset shift:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><em>\u00ab\u00a0Secure by default\u00a0\u00bb is not enough \u2014 controls must be provable.<\/em><\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">4. Monitoring &amp; Incident Management<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What auditors expect<\/h3>\n\n\n\n<p>DORA requires <strong>continuous monitoring<\/strong>, not periodic checks. Auditors verify that third-party services are monitored, incidents are detected, and evidence is retained and traceable.<\/p>\n\n\n\n<p>They look for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>live or historical monitoring data,<\/li>\n\n\n\n<li>alerts tied to third-party services,<\/li>\n\n\n\n<li>visibility into CI\/CD platform availability and integrity.<\/li>\n<\/ul>\n\n\n\n<p>Monitoring evidence must demonstrate that third-party degradation would be detected and incidents would be escalated within defined timelines. Static risk assessments alone are insufficient.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Evidence to provide<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitoring dashboards (availability, integrity signals)<\/li>\n\n\n\n<li>Incident logs involving third-party services<\/li>\n\n\n\n<li>Evidence of incident escalation and notification<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical evidence artifacts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Logs and metrics from CI\/CD and cloud platforms<\/li>\n\n\n\n<li>Incident tickets referencing third-party providers<\/li>\n\n\n\n<li>SIEM or observability integration evidence<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Auditor View<\/h3>\n\n\n\n<p>Auditors assess whether:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>third-party services are <strong>continuously monitored<\/strong>,<\/li>\n\n\n\n<li>incidents involving suppliers are detectable,<\/li>\n\n\n\n<li>incident handling is documented and traceable.<\/li>\n<\/ul>\n\n\n\n<p>They reject annual risk assessments without operational monitoring.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Engineer View<\/h3>\n\n\n\n<p>Engineers ensure:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CI\/CD platforms, registries, and cloud runtimes emit logs,<\/li>\n\n\n\n<li>monitoring feeds SIEM or centralized logging,<\/li>\n\n\n\n<li>incidents reference affected third-party providers.<\/li>\n<\/ul>\n\n\n\n<p>Typical implementation:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>observability pipelines,<\/li>\n\n\n\n<li>incident tickets linked to logs and metrics,<\/li>\n\n\n\n<li>alerting on supplier degradation or failure.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Incident Notification SLAs: Tested in Reality<\/h3>\n\n\n\n<p>Auditors verify that:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>incident notification SLAs exist contractually,<\/li>\n\n\n\n<li>internal processes can receive and act on notifications,<\/li>\n\n\n\n<li>timelines are realistic and tested.<\/li>\n<\/ul>\n\n\n\n<p>They often request past incident examples, timestamps showing notification delays, and evidence of escalation and response. An SLA that has never been exercised is treated as <strong>unproven<\/strong>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">5. Exit Strategy &amp; Resilience<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What auditors expect<\/h3>\n\n\n\n<p>Exit strategies must be <strong>realistic and tested<\/strong>. Auditors will challenge whether exit plans exist, whether they apply to critical providers, and whether they have ever been tested.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Evidence to provide<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Documented exit strategies per critical provider<\/li>\n\n\n\n<li>Evidence of exit or fallback testing<\/li>\n\n\n\n<li>DR \/ BCP test results involving third-party dependencies<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical evidence artifacts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Exit plans and transition procedures<\/li>\n\n\n\n<li>Test reports or tabletop exercise outputs<\/li>\n\n\n\n<li>Dependency replacement or fallback documentation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Auditor View<\/h3>\n\n\n\n<p>Auditors ask:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do exit strategies exist for critical suppliers?<\/li>\n\n\n\n<li>Have they been <strong>tested<\/strong>?<\/li>\n\n\n\n<li>Could you realistically exit under pressure?<\/li>\n<\/ul>\n\n\n\n<p>A PDF exit plan alone is insufficient.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Engineer View<\/h3>\n\n\n\n<p>Engineers support exit strategies by:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>avoiding hard vendor lock-in,<\/li>\n\n\n\n<li>documenting replacement or fallback paths,<\/li>\n\n\n\n<li>participating in DR and exit tests.<\/li>\n<\/ul>\n\n\n\n<p>Typical implementation:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>artifact portability,<\/li>\n\n\n\n<li>infrastructure-as-code reproducibility,<\/li>\n\n\n\n<li>tested backup and restore procedures.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Evidence Quality: How Auditors Judge Credibility<\/h2>\n\n\n\n<p>Auditors assess evidence against four implicit criteria:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Objectivity<\/strong> \u2013 system-generated, not manually edited<\/li>\n\n\n\n<li><strong>Traceability<\/strong> \u2013 linked to a specific supplier or control<\/li>\n\n\n\n<li><strong>Continuity<\/strong> \u2013 produced consistently over time<\/li>\n\n\n\n<li><strong>Integrity<\/strong> \u2013 protected against alteration<\/li>\n<\/ol>\n\n\n\n<p>Evidence failing any of these criteria weakens the entire pack. Manual spreadsheets alone rarely meet these criteria.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Common Article 28 Audit Findings (Red Flags)<\/h2>\n\n\n\n<p>Auditors frequently raise findings when they see:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>supplier inventories not linked to CI\/CD tooling,<\/li>\n\n\n\n<li>contracts without operational enforcement,<\/li>\n\n\n\n<li>monitoring limited to annual reviews,<\/li>\n\n\n\n<li>no proof of subcontractor visibility,<\/li>\n\n\n\n<li>exit plans that were never tested.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Situation<\/th><th>Auditor Reaction<\/th><\/tr><\/thead><tbody><tr><td>\u00ab\u00a0We trust this SaaS provider\u00a0\u00bb<\/td><td>\u274c Not acceptable<\/td><\/tr><tr><td>Evidence collected manually before audit<\/td><td>\u26a0\ufe0f Weak control<\/td><\/tr><tr><td>Logs exist but are not retained<\/td><td>\u274c Non-compliant<\/td><\/tr><tr><td>Exit plan never tested<\/td><td>\u274c High-risk finding<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>From audit experience, evidence packs often fail because:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CI\/CD SaaS platforms are excluded from supplier scope<\/li>\n\n\n\n<li>Evidence exists but cannot be linked to a control<\/li>\n\n\n\n<li>Logs are available but not retained long enough<\/li>\n\n\n\n<li>Incident SLAs exist but were never tested<\/li>\n\n\n\n<li>Exit strategies are documented but unsupported by technical reality<\/li>\n<\/ul>\n\n\n\n<p>These issues usually surface <strong>during the audit<\/strong>, not during preparation. Designing evidence into pipelines avoids these gaps.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">How CI\/CD Architecture Enables Article 28 Compliance<\/h2>\n\n\n\n<p>Modern Article 28 compliance depends heavily on CI\/CD and cloud architecture:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>pipelines enforce access and approvals,<\/li>\n\n\n\n<li>SBOMs provide supply chain transparency,<\/li>\n\n\n\n<li>logs and audit trails generate evidence automatically,<\/li>\n\n\n\n<li>monitoring systems detect third-party failures.<\/li>\n<\/ul>\n\n\n\n<p>Without CI\/CD-level evidence, Article 28 compliance remains fragile.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Designing for Both Views<\/h2>\n\n\n\n<p>The most mature organizations:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>design controls <strong>once<\/strong>,<\/li>\n\n\n\n<li>satisfy <strong>both<\/strong> audit and engineering needs,<\/li>\n\n\n\n<li>generate evidence continuously via CI\/CD and cloud platforms.<\/li>\n<\/ul>\n\n\n\n<p>This is the foundation of <strong>continuous compliance<\/strong> under DORA.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Final Takeaway<\/h2>\n\n\n\n<p>DORA Article 28 is not a documentation exercise \u2014 it is an <strong>operational control problem<\/strong>.<\/p>\n\n\n\n<p>The strongest evidence packs:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>integrate CI\/CD, cloud, and vendor governance,<\/li>\n\n\n\n<li>generate evidence continuously,<\/li>\n\n\n\n<li>align architecture, contracts, and monitoring.<\/li>\n<\/ul>\n\n\n\n<p>If auditors can verify controls without relying on explanations, your Article 28 posture is solid.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Recommended Related Reading<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-security\/dora-article-28-architecture-third-party-ict-risk-controls-across-ci-cd-and-cloud\/\" data-type=\"post\" data-id=\"339\">DORA Article 28 Architecture \u2014 Explained<\/a><\/strong><\/li>\n\n\n\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-security\/continuous-compliance-via-ci-cd-pipelines\/\" data-type=\"post\" data-id=\"334\">Conformit\u00e9 continue via les pipelines CI\/CD<\/a><\/strong><\/li>\n\n\n\n<li><strong><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/ci-cd-audit-red-flags-what-immediately-raises-auditor-concerns\/\" data-type=\"post\" data-id=\"264\">CI\/CD Audit Red Flags<\/a><\/strong><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n    <section class=\"rds-author-box rds-author-box--audit\"\r\n             dir=\"ltr\" lang=\"fr\"\r\n             style=\"border:1px solid rgba(100,116,139,.35);border-radius:14px;padding:16px 18px;margin:26px 0 18px;background:rgba(148,163,184,.08);\">\r\n      <strong style=\"margin:0 0 8px; font-size:14px; font-weight:700; letter-spacing:.02em;\">Contexte \u201caudit-ready\u201d<\/strong>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">Contenu con\u00e7u pour les environnements r\u00e9glement\u00e9s : contr\u00f4les avant outils, enforcement par politiques dans le CI\/CD, et evidence-by-design pour l\u2019audit.<\/p>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">Focus sur la tra\u00e7abilit\u00e9, les approbations, la gouvernance des exceptions et la r\u00e9tention des preuves de bout en bout.<\/p>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">\r\n        <a href=\"https:\/\/regulated-devsecops.com\/fr\/fr\/about\/\">Voir la m\u00e9thodologie sur la page About.<\/a>\r\n      <\/p>\r\n    <\/section>\r\n    \n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introduction DORA Article 28 exige des entit\u00e9s financi\u00e8res r\u00e9glement\u00e9es qu&rsquo;elles d\u00e9montrent un contr\u00f4le efficace des risques tiers ICT. Cette obligation va bien au-del\u00e0 des questionnaires fournisseurs ou des d\u00e9clarations contractuelles. Les auditeurs n&rsquo;\u00e9valuent pas l&rsquo;intention \u2014 ils \u00e9valuent les preuves. Cet article fournit un pack de preuves pratique pour DORA Article 28, se concentrant sur &#8230; <a title=\"DORA Article 28 \u2014 Pack de preuves\" class=\"read-more\" href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dora-article-28-evidence-pack\/\" aria-label=\"En savoir plus sur DORA Article 28 \u2014 Pack de preuves\">Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[126,122,123],"tags":[],"post_folder":[],"class_list":["post-1366","post","type-post","status-publish","format-standard","hentry","category-regulatory-frameworks","category-audit-evidence","category-ci-cd-governance"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts\/1366","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/comments?post=1366"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts\/1366\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/media?parent=1366"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/categories?post=1366"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/tags?post=1366"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/post_folder?post=1366"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}