The Controls You Cannot Descope

Anaplan announced on 10 September 2026 that it achieved ISO/IEC 42001 certification, and the press release carried the usual language about transparent governance, lifecycle controls, and independent verification. The certificate was issued on 13 August 2026 by Bay Mountain Security, putting Anaplan among the first enterprise-performance-management platforms to reach the standard. The announcement arrived 17 days before the 2 August 2026 general-application date of the EU AI Act, when Annex III high-risk AI obligations became enforceable. The timing was not a coincidence. The timeline was the constraint, and every engineer inside a vendor knew what that meant: you ship what the auditor will pass, not what the standard says you should build.

ISO/IEC 42001 Annex A defines 38 controls grouped into nine areas, covering AI policy, impact assessment, the AI lifecycle, and data governance. Certification runs a Stage 1 and Stage 2 audit, is valid for three years, and carries annual surveillance audits. The standard does not specify which controls you must implement. You select controls and write a Statement of Applicability that decides which apply to you. The engineer's job is to decide which controls can be justified as out-of-scope without the auditor marking it a major nonconformity. That decision is where the certificate gets made.

1. A.6.1, the AI system impact assessment. This is the highest-effort control in practice, and it cannot be descoped because it is the one thing the EU AI Act explicitly requires for high-risk systems under Article 27. You run the assessment, you fill the template, you get sign-off from legal and product. The catch is that the assessment is a point-in-time document. If your model changed between the Stage 1 audit and the day the certificate was issued, and the new version introduced retrieval over a corpus you had not previously impact-assessed, you now have a compliant certificate covering a system configuration you are no longer running. The engineer files the deviation in a change log and schedules it for the first surveillance audit. The certificate does not break. The surveillance audit is in twelve months, and by then the model will have changed again.

2. A.7.x, data quality and provenance. The standard asks you to document where your training data came from, how it was cleaned, and whether it carries the bias your impact assessment said you would monitor. The reality is that if you fine-tuned on a foundation model whose provider will not give you the base-model data card, you document what you have access to and mark the rest as a third-party dependency under A.10. The auditor asks whether you requested the documentation from the provider. You produce the email thread. The auditor notes it and moves on. You are compliant with your own process, which is what the standard certifies. The data provenance gap does not close, but the certificate issues.

3. A.10.x, third-party AI assurance. This is surprisingly hard once you start asking foundation model vendors for documentation. If your product uses OpenAI via Azure OpenAI Service, you are dependent on a model whose weights, training data, and red-team results are not published. The control asks you to assess third-party AI risk. You assess what you can: the API's regional endpoints, the data-residency guarantees in the Microsoft contract, the abuse-monitoring retention window. You write a residual-risk statement that says the foundation-model layer is accepted as a black box, and you cite the vendor's own SOC 2 report as evidence that they have a control environment, even though SOC 2 does not audit AI-specific risks. The auditor accepts it because there is no other path. Descoping A.10 would mean admitting you do not manage third-party AI risk at all, and that would be a finding. Accepting residual risk and documenting it is compliant.

4. Monitoring and measurement. Clause 9 asks for continual performance evaluation. The system you shipped logs inference latency, error rates, and API call volume. It does not log the demographic distribution of users whose queries were rejected by the content filter, because that would require demographic tagging you do not collect and a fairness measurement framework you do not have built. You document the metrics you do track, you write a MEASURE 2.1 procedure that says fairness metrics are under evaluation for future implementation, and you schedule it as a roadmap item. The auditor sees a gap between what you measure and what the AI RMF would recommend, but the standard does not mandate a specific measurement, only that you define and track what matters to your context. You defined it. The gap is noted as an observation, not a nonconformity. The certificate issues.

5. The AI policy. Clause 5 asks for top-management commitment to responsible AI, documented and communicated. You produce the two-page policy the chief product officer signed in May, the training deck that went to the engineering org in June, and the acknowledgment log showing 94% of staff completed the module. The policy says the company will deploy AI "in alignment with our values". It does not define those values in measurable terms, and it does not specify what happens when a feature request conflicts with them. The auditor does not ask, because the standard does not require operationalized values, only that a policy exists and is communicated. You are compliant.

6. The AIMS scope statement. You scoped the certification to the AI features launched before June 2026. The agent-based planning assistant you demoed at the user conference in August is not in scope, because it was not in production at the time of the Stage 2 audit. The certificate covers the systems the auditor reviewed. The new agent goes live in October, and it will be added to scope at the next surveillance cycle. For three months, your highest-profile AI feature is not covered by the certificate your marketing site now advertises. The customer reading the trust centre does not know that. The engineer does.

Certification takes 6 to 12 months and costs $5,000 to $30,000 for initial audit, depending on organization size and system complexity. The cost is not the constraint. The constraint is the speed at which you can produce the documented evidence an auditor will accept while the product is still shipping weekly. ISO 42001 certification does not satisfy EU AI Act obligations on its own, but the risk assessments and governance structures built for it feed directly into the technical documentation the Act requires. That is why the certificate mattered in August 2026. The AI Act's high-risk provisions went live, and procurement teams at banks and insurers started adding "ISO 42001 certified or roadmap" to vendor questionnaires. Fortune 500 buyers added those clauses through 2025, and by mid-2026 not having a certificate was a deal risk.

The certification is real. The audit happened, the nonconformities were closed, and the certificate is valid for three years. What the engineer knows is that the system the auditor certified is not the system running in production today, and it will not be the system running in production next month. The controls the standard defines are written for a world where the AI system has a fixed architecture, a known training set, a stable set of third-party dependencies, and a measurement framework that was designed before the first user logged in. The system you shipped has none of those things, because you shipped it in seven months to meet a compliance deadline that arrived whether you were ready or not. The certificate says you have a management system. The management system says you have a process for handling change. The process has a backlog of 19 items tagged "post-certification remediation", and the next surveillance audit is in eleven months.

ISO 42006, published on 7 July 2025, is now moving into accreditation programs during 2026, tightening the rules for organizations that audit and certify ISO 42001 by adding AI-specific competence requirements and structured audit-time calculations, with accreditation bodies like ANAB and European Accreditation making it mandatory. The bar is rising. The vendor that certified in August 2026 got in before the tightened auditor-competence rules fully landed. The vendor certifying in August 2027 will face an auditor who has passed an AI-risk-assessment exam and who has been told to calculate audit days based on model complexity, not just organizational headcount. The controls you could justify as residual risk in 2026 will be findings in 2027.

The EU AI Act does not reference ISO 42001. It asks for risk-management systems, technical documentation, logging, and human oversight. The certification gives you a scaffold to build that documentation on, and it gives procurement a checkbox. What it does not give you is a system that was built for auditability from the beginning. You retrofitted the controls onto a product that shipped two years before the standard was published, and you did it in the time between when the AI Act's final text was released and when enforcement began. The distance between the standard and the system is the engineer's daily work, and it is the part the certificate does not show.

Tarry Singh is the founder and CEO of Real AI (realai.eu), an enterprise AI advisory and deployment firm working with global enterprises on production agent systems, model risk, and AI sovereignty strategy. He also leads Earthscan (earthscan.io) for Energy AI, and is a founding contributor to the EU-funded HCAIM and PANORAIMA programmes for responsible AI education across European universities. He writes at tarrysingh.com.