The best candidate for most of them is ISO 27017, for cloud services. Almost every organization today is either a cloud customer or a cloud provider. Many are both.

Here’s what these standards add, what that looks like for one real control, and how to start.

Three levels of guidance

Think of the guidance for a control in three levels:

1. Annex A tells you what. One sentence per control, 93 controls in four chapters: organizational, people, physical, technological.

2. ISO 27002 tells you how, for everyone. For each control, it gives you a purpose and implementation guidance. It’s written to fit any organization.

3. The sector and context standards tell you how, for your situation. They take the 27002 guidance, make it more specific for their context, and add controls that 27002 doesn’t have.

ISO/IEC 27000:2026 calls these standards “candidate necessary information security controls” (clause 5.3). Under ISO 27001, clause 6.1.3 b), you can take your controls from any source. Annex A stays the cross-check.

Read more

Last week, ISO published a standard on exactly that: ISO/IEC 27090:2026, Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems.

In my work, I no longer see a single organization that doesn’t develop, build or use AI systems. So technically, every ISMS is affected, and this standard is relevant to almost everyone.

Here’s what’s inside, and the one thing you need to know before you add it to your ISMS.

What ISO 27090 covers

The standard is guidance on understanding, detecting and mitigating security threats that are specific to AI systems, across their whole life cycle: from training data to the deployed model.

It describes a range of attack types, among them:

• Poisoning: someone manipulates training data or the model so the system learns the wrong thing.

• Evasion: carefully crafted inputs make the model misjudge what it sees.

• Membership inference and model inversion: an attacker works out which data the model was trained on, or reconstructs it.

• Model stealing: someone copies a trained model through queries that look perfectly legitimate.

• Prompt injection and output injection: attacks on AI systems in operation, through what goes in and what comes out.

For each threat, you get a short description, the possible consequences and how to detect and mitigate it.

The standard also makes clear that established security practices remain essential. AI adds risks on top of the ones you already manage. It doesn’t replace them.

The catch: it describes controls, but it’s not a control standard

ISO/IEC 27000:2026 sorts the standards around ISO 27001 into categories. One of them is standards that give guidance on controls you can determine as necessary under ISO 27001, clause 6.1.3 b). That category lists ISO/IEC 27002, 27010, 27011, 27017 and 27019. ISO 27090 isn’t on that list.

These standards are built around controls. ISO 27002 gives you 93 controls, each with attributes, a purpose and implementation guidance. The sector standards, like ISO 27017 for cloud services, add guidance for their context.

ISO 27090 is built around threats. But read the mitigations for each threat, and what you find are clearly controls:

So you can’t take ISO 27090 and tick off its “controls” in your SoA. There’s no control list to tick off. It describes mitigations, and you decide which of them you need.

o which is it? A threat catalogue for your risk assessment, or a control catalogue next to ISO 27002? The standard clearly describes controls. But in the terms of ISO 27000, it isn’t one of the standards with candidate controls, at least not today.

Where it fits in your ISMS

Remember last week’s issue on the Statement of Applicability? Your risks and your controls come first. Annex A comes second, as a safety net. Here’s how the standards around ISO 27001 connect to that sequence:

My answer: both. And the two go hand in hand. You have to know your threats to determine the controls you need. That’s why ISO 27090 connects to both clause 6 and Annex A. Use it at both points:

1. Risk assessment (6.1.2): use its threat descriptions to identify risks for the AI systems in your scope. This is where poisoning or model stealing get into your risk register.

2. Risk treatment (6.1.3 b): use its mitigations as a source for your controls. ISO 27001 explicitly allows controls to be designed as required or identified from any source.

3. Cross-check (6.1.3 c): compare your controls with Annex A, as always, and record them in your SoA.

Here’s what that looks like for Barvello Coffee Systems, the fictional company from my courses. It runs a customer support chatbot from a vendor.

• Threat (from ISO 27090): prompt injection

• Risk R-AI-01: a customer manipulates the chatbot into showing another customer’s order data

• Controls in the SoA:

None of these rows says “implement ISO 27090”. Each control is specific, testable and traceable to a risk, and Annex A does what it was designed for: the cross-check.

If you’re working with ISO 42001, the logic is the same: ISO 27090 feeds your AI risk assessment. It doesn’t replace the controls you determine.

Try it this week: list the AI systems in your ISMS scope, including the ones you buy, like a chatbot on your website or a copilot in your office suite. For each one, go through the five threats above and ask two questions: could this happen to us, and which control do we already run against it? Every “yes, and none” belongs in your risk register.

This Friday: How to use ISO 27090 with ISO 27001

On Friday, October 23, at 3 PM CEST (9 AM ET), I’m going live on Substack.

We’ll look at the standards that feed your controls and how they work together:

• What ISO 27001 actually requires when you determine your controls, and why Annex A is a cross-check, not the source

• How ISO 27002 and the sector standards (27011, 27017, 27019) relate to ISO 27001 and to each other

• How to bring ISO 27090 into the mix: from an AI threat to a risk to a control in your SoA

• What I look at as an auditor when an ISMS scope includes AI systems

Bring your questions. There’s a live Q&A at the end. It’s free.

Join the live masterclass →

See you on Friday, Aron

P.S. Is there an AI system in your ISMS scope today? Just reply with a number: (1) yes, we build one, (2) yes, we use one from a vendor, (3) no, (4) not sure. I read every reply.

Open their Statement of Applicability, and you often can’t tell which is which.

Here’s what that looks like. Two companies, both ISO 27001 certified: a 12-person startup and a cloud provider with 40,000 employees. Row A.8.5, Secure authentication, in both SoAs:

Now look at what the two companies actually do. None of this appears in their SoAs:

• The startup: everyone logs in with a password and an authenticator app.

• The cloud provider: hardware security keys for every administrator, single sign-on with conditional access, phishing-resistant MFA for all staff, and certificate-based authentication between systems.

Both can be exactly right. A 12-person startup doesn’t need what a hyperscaler needs. Different risks, different controls.

But nobody reading the SoA can tell the difference.

What a certificate actually tells you

An ISO 27001 certificate confirms that an organization has established an ISMS that meets the requirements of the standard and is capable of achieving its information security objectives.

That’s it. It doesn’t tell you how secure the organization is, and it was never meant to.

The Statement of Applicability is supposed to fill that gap. It’s the one document that should explain how a company treats its specific risks. When every SoA looks the same, so does every certificate.

How almost every SoA is built

Ctrl+C. Ctrl+V.

A spreadsheet with Annex A copied in, plus three extra columns:

1. Applicable? (Yes/No)

2. Status (Implemented/Not implemented)

3. Justification for inclusion/exclusion

Fill in the columns, done.

Notice something? The standard never asks for an “Applicable” column. It asks you to justify why each control is included, and why any Annex A control is excluded. A Yes/No answers neither.

Subscribe now

What ISO 27001 actually asks for

Clause 6.1.3 describes a sequence. The organization has to:

1. Determine all controls that are necessary to treat its risks.

2. Compare them with Annex A to make sure no necessary control has been missed.

3. Produce the SoA: the necessary controls, why they’re included, whether they’re implemented, and why any Annex A controls are excluded.

Your risks and your controls come first. Annex A comes second, as a safety net.

That’s also why you can’t “implement” A.8.5. In essence, it asks you to authenticate securely, in line with your access rules. It doesn’t name a technology, a configuration, or where to apply it, because that depends entirely on your risks. What you implement are specific controls that achieve it.

The structure I recommend instead

Turn the SoA around. Start with your controls, then map them to Annex A:

Three things change:

• Every row points to a risk. That’s your justification for inclusion, and it’s specific.

• Every control is testable. An auditor, a customer or your own internal auditor can check it.

• Annex A does what it was designed for. Any Annex A control that no row maps to needs a justified exclusion. That’s your cross-check.

Try it this week: take the three biggest risks from your risk register. For each one, write down the specific controls you actually run. Then map them to Annex A. If a row in your current SoA can’t be traced back to one of them, you’ve found where to start.

What the copy-paste costs you

• Your certificate says what everyone else’s says. A customer can’t tell from your SoA whether you’re the startup or the cloud provider.

• Your customers send the questionnaire anyway. Because the SoA doesn’t tell them what you do, they ask a few hundred questions to find out.

• The SoA is useless as a tool. It can’t guide your internal audits, bring a new CISO up to speed, or show anyone what your security program actually looks like.

An honest note from the auditor’s chair

Most auditors accept an SoA that’s a copied Annex A. I have too. It usually passes.

But passing the audit isn’t the bar. Organizations that build their SoA the way the standard intends get a document that works for them, not just for the auditor.

This Friday: Why your SoA is not compliant

On Friday, October 16, at 3 PM CEST (9 AM ET), I’m going live on Substack.

We’ll take a typical copy-paste SoA and rebuild it, step by step:

• From a risk to a necessary control that you can actually test

• How to structure the SoA around your controls and map them back to Annex A

• How to write justifications for exclusions that hold up in an audit

• What I look at as an auditor when I open an SoA

Bring your own SoA and your questions. There’s a live Q&A at the end. It’s free.

Join the live masterclass →

Be the GRC Practitioner AI can’t replace,

— Aron

P.S. What does the justification column in your SoA say for A.8.5? Hit reply and tell me. I read every answer, and the most common ones will make it into Friday’s session.

A BIA makes the time dimension visible. For each business activity, you ask how the impact develops over hours, days and weeks, and how much data the business can afford to lose. The point where the impact becomes unacceptable is your maximum tolerable period of disruption (MTPD). From there, you set your RTOs and RPOs and map them to the systems behind each activity.

Now your impact scores are derived, not negotiated. And every availability control in your Statement of Applicability has a reason an auditor can trace straight back to the business.

In this masterclass, I walk you through the entire method, using a beer brewery as an example.

Be the GRC Practitioner AI can’t replace.

– Aron

Most people won’t read it. It’s “just the overview document,” after all.

That’s a mistake. Buried in the new text are two passages that address concepts the large majority of ISO 27001 …

Read more

Then the audit happens, an…

Read more

Here’s the inconvenient detail: ISO 42001 is a management system standard. The clue is in the name — Artificial Intelligence Management System (AIMS). It sits in the same structural family as ISO 27001…

Read more

Underneath it you’ll find a quick changelog of what moved and why.

The full 12-step approach

1. Scope of the ISMS

2. Gap Analysis

3. Management Support

4. Information Security Policy

5. Asset Inventory

6. Risk Management Methodology

7. Risk Assessment

8. Risk Treatment

9. Competence & Awareness

10. Performance Evaluation

11. Continual Improvement

12. Certification Audit

Changelog: what changed and why

🔄 Scope is now Step 1 (used to be step 2) You can't plan, assess, or resource anything until you've defined what your ISMS actually covers — and that includes the business case you'll put in front of leadership. Scope sets the boundaries; the gap analysis then measures your current state against the standard within those boundaries; and together they tell you what the project will really involve in terms of effort, cost, and resources. That's exactly what management needs to see to commit. Put scope anywhere but first, and the business case you bring to leadership in Step 3 is built on shaky ground.

🔄 Gap Analysis now comes before Management Support You shouldn’t ask leadership for commitment based on guesswork. Running the gap analysis first means you walk into that conversation with real evidence — what’s missing, what it’ll cost, what resources you’ll need. A business case built on facts is far harder to say no to.

🔄 Competence & Awareness moved to Step 9, after Risk Assessment and Risk Treatment This is the change I’m most pleased with. Once you’ve assessed your risks and defined your risk treatment plan, you finally know what your people actually need to be competent in and aware of. Training can then target the real risks and the specific controls you’ve chosen to implement — instead of being generic. You educate people on what matters, because by this point you know what that is.

The takeaway

The thread running through every one of these changes is the same: each step should produce what the next step needs. Scope defines the boundaries for the gap analysis. The gap analysis builds the business case for management support. Risk assessment and treatment tell you what to train people on. When the order reflects those dependencies, the whole project becomes easier to plan, easier to resource, and easier to explain to an auditor.

If you want the complete walkthrough, the video above covers all twelve steps in detail.

From ZERO to AUDIT-READY in 12 Steps

If you are responsible for an ISO 27001 implementation project, you are fighting a battle against the clock.

The standard tells you WHAT must be done,

but it leaves the HOW entirely to your imagination.

This leaves you staring at a blank map, forced to build an ISMS from scratch while the deadline approaches.

Our ISO 27001 Lead Implementer Framework gives you the Roadmap, Project Plan, Templates and Training to be audit-ready in months, not years.

Get access now

Last week I posted a scenario on LinkedIn and asked my network a deceptively simple question: how would you rate this finding?

The poll drew 258 votes, and the split was telling:

Read more

So when Dejan Kosutic, Advisera’s CEO, reached out to have me on his Secure & Simple Podcast, it genuinely felt surreal. A no-brainer to say yes, but s…

Read more

The answer is: not necessarily — and that’s completely fine.

There are t…

Read more

While the previous version (C5:2020) wa…

Read more

In that moment, your heart rate spikes. We have been conditioned to see audits as a pass-or-fail exam—a binary world where you are either a compliant hero…

Read more

The response is often a confident, “Yes, we are ISO 27001 certified.”

That answer is misleading.

Read more

This edition of GRC Lab is brought to you by … Kertos

Europes #1 Compliance Platform Kertos, automates your compliance standards, such as ISO 27001, GDPR, SOC 2, or the EU AI Act – from the initial analysis to the audit and as a sustainable solution far beyond.

Discover Kertos

In this session, we cover:

• The “Planning” vs. “Execution” Trap: Clarifying the difference between Clauses 6.1.2 and 8.2.

• The 3 Pillars of Assessment: A detailed look at Risk Identification, Risk Analysis, and Risk Evaluation.

• Risk Owners: Who they actually are (hint: it’s usually not the IT department).

• Methodologies Explained:

  • Qualitative Analysis: How to use a Risk Matrix (Likelihood vs. Impact).

  • Quantitative Analysis: How to calculate Single Loss Expectancy (SLE) and Annualized Loss Expectancy (ALE).

• Real-World Scenario: A practical example involving a Data Center in Hawaii and... a volcano. 🌋

Learn ISO 27001 Together with Me

Watching videos is a great start, but implementing an entire ISMS requires a structured approach combined with advice from those who already did it.

If you are ready to master the standard and get certified, I invite you to enroll in my ISO 27001 Lead Implementer Course.

New Update: I have recently upgraded the program. You now have the unique opportunity to work directly with me inside the course. Whether you are stuck on risk methodology or need a second pair of eyes on your scope, I’m here to help you cross the finish line.

Enroll Today

But there is a catch. This window is closing very soon.

Here is how to grab your copy before the rules change.

This edition of GRC Lab is brought to you by … Kertos

Europes #1 Compliance Platform Kertos, automates your compliance standards, such as ISO 27001, GDPR, SOC 2, or the EU AI Act – from the initial analysis to the audit and as a sustainable solution far beyond.

Discover Kertos

What is ISO 27000?

The ISO 27000 family of standards is a set of guidelines developed by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) under the joint ISO and IEC subcommittee, ISO/IEC JTC 1/SC 27. Its purpose? To offer organizations a robust and comprehensive framework for managing and improving their information security.

The ISO 27000 series is not just one standard but a suite of inter-related standards, each providing guidelines and requirements addressing various aspects of information security. Together, they form a cohesive model for implementing and managing a robust Information Security Management System (ISMS).

ISO 27000 is the “root” of this family. It doesn’t tell you what to do. Instead, it explains the terms and the big picture. It defines the vocabulary so everyone on your team speaks the same language.

The Four Categories

The family is split into four main groups:

• Terminology: Standards like ISO 27000 that define words and concepts.

• Requirements: These are “normative” standards. They are the only ones you can be audited against. ISO 27001 is the most famous example.

• General Guidelines: These explain how to meet the requirements. ISO 27002 is a great example of this.

• Sector-Specific Guidelines: These are for specific industries, like telecommunications or healthcare.

Why it is free (for now)

ISO typically offers terminology standards for free on their website. Since the current version of ISO 27000 is mostly about definitions, it costs zero dollars.

But a new version is coming in early 2026. This update will include more than just definitions. It will cover principles and relationships between standards. Because it has more content, ISO will likely start charging for it.

How to get it

1. Go to iso.org.

2. Search for ISO 27000.

3. Add the current version to your cart.

4. Check out for free and download the PDF.

Ready to stop learning in isolation?

You’ve just read about the theory, but implementing GRC in the real world is a different beast. For years, I only offered digital courses where you had to figure out the hard parts alone.

That changes now.

I have opened the doors to the GRC Lab. This is no longer just a library of on-demand videos; it is a direct line to me and a community of peers.

When you join, you get:

• Access to Me: Weekly live Q&A sessions to solve your specific roadblocks.

• Expert Workshops: Deep dives into topics AI can’t teach you.

• The Full Course: My complete ISO 27001 Lead Implementer training.

• And so much more!

Enroll today

Subscribe now

Read more

Subscribe now

Read more