Roads to trust

The road for any framework

Use it when a law, a standard or a customer demands proof. The same nine steps lead through any of them, so every framework becomes a variation on this road.

1. Name the obligation

   What is required, of whom, by when, and who decides it is met: a law, a standard, a customer.

2. Set the scope

   Which systems, services, people and data are in. Write it down first.

3. Map requirements to controls

   One control can answer many requirements, so write it once.

4. Find the gaps

   Compare what really happens with what the controls expect, and keep the evidence.

5. Give every control an owner

   A named person, a date and a priority ranked by risk. A plan nobody owns is a wish.

6. Build and operate

   Policies people can follow and controls that run. Evidence should fall out of the work.

7. Check yourself

   An internal review and a management review before anyone external looks.

8. Get independent assurance

   Where the framework asks for it: an auditor, a certification body or a notified body. A law may instead be enforced by a regulator, with no audit step to pass.

9. Keep it alive

   Monitoring, change control and a yearly rhythm, so the next audit is routine.

Where AI and automation help

• Keeping the requirement-to-control map, owners and evidence linked.
• Collecting evidence on a schedule and checking it against the control.
• Watching for drift: a control that stopped running, an overdue review, a claim with no artefact behind it.

Traps that cost the most time

• Starting with documents instead of scope.
• A control map copied from a template that nobody can explain.
• Evidence that exists only in one person's head.
• Treating the audit as the finish line.

The road to SOC 2

Use it when customers ask for assurance. SOC 2 is an auditor's report on how your controls meet the Trust Services Criteria. The report is the product: customers read it instead of sending you a questionnaire.

1. Choose the scope

   Which services and systems, and which criteria. Security is always in; availability, confidentiality, processing integrity and privacy are added when customers ask.

2. Describe the system and assess risk

   Management's description of the system, and a risk assessment that explains why each control exists. Auditors read both before they test anything.

3. Find the gaps

   Compare what you do today with what the criteria expect. A short readiness assessment saves months later.

4. Write down the controls

   Policies people can follow, named owners, and controls that fit how the team really works.

5. Collect evidence from day one

   Tickets, reviews, access lists and test results already exist; capture them as they happen.

6. Type I: controls as designed

   A CPA firm reports on whether the controls are suitably designed at a point in time. It is the fastest first report. SOC 2 is an attestation, not a certification, and the report is normally shared with customers under restricted use.

7. Type II: controls in operation

   The same controls shown working over an observation period, often three to twelve months. Customers usually value this report most.

Where AI and automation help

• Pulling evidence from systems on a schedule and checking it against the control, instead of screenshots at audit time.
• Drafting policies and control descriptions from your real practice, for a person to review and approve.
• Watching for drift: a control that quietly stopped running, an overdue access review.

Traps that cost the most time

• Writing policies nobody follows. The auditor tests what happens, not what the document says.
• Scope that grows during the audit. Decide it early and write it down.
• Evidence nobody owns. Every control needs a named person who checks it.

SOC suite and criteria (AICPA) ↗↗ More references in the library →

The road to ISO 27001

Use it when you need an independent, certified proof of how you run information security. ISO 27001 certifies a management system, not a product: a way of working that keeps improving and that an independent body checks.

1. Understand the context

   Who depends on you, what the law and contracts require, and what must be protected.

2. Set scope and policy

   Which parts of the organisation and which assets are in. Top management owns the policy.

3. Assess and treat risk

   A repeatable risk method, a register with owners, and decisions to reduce, accept, transfer or avoid.

4. Select the controls

   Choose from the Annex A controls (ISO/IEC 27001:2022) and record choices and reasons in the Statement of Applicability.

5. Run the system

   Operate the controls, train people, monitor, and keep the records that show it.

6. Audit yourself, then review

   An internal audit, corrective actions for its findings, and a management review before the certification body arrives.

7. Certification and the cycle

   A two-stage audit by an accredited certification body, yearly surveillance audits, and recertification at the end of the three-year cycle.

Where AI and automation help

• Keeping the risk register, control list and evidence linked.
• Tracking review dates, overdue tasks and corrective actions, and nudging the owners.
• Preparing the internal audit: sampling, evidence checks and a first list of findings for the auditor to confirm.

Traps that cost the most time

• Treating it as a document project. Auditors look for a system that runs and improves.
• A Statement of Applicability copied from a template with reasons nobody can explain.
• Letting the management review become a formality. It is where decisions are recorded.

ISO/IEC 27001 (ISO) ↗↗ More references in the library →

The road to ISO/IEC 42001

Use it when you develop, provide or use AI and need a way of governing it that an independent body can check. ISO/IEC 42001 is a management system standard for AI, published in 2023. If you already run ISO 27001, the structure is shared and much can be reused.

1. Understand your role

   Do you develop AI, provide it or use it? Who depends on it, and what do the law and your customers expect?

2. Set scope and an AI policy

   Which AI systems and parts of the organisation are in, and a policy that top management owns.

3. Inventory the AI systems

   Every system, its owner, the data it uses and the suppliers behind it. You cannot manage what you cannot see.

4. Assess risk and impact

   AI risks for the organisation, and an impact assessment of each system on the people it touches. Repeat when a system changes.

5. Select the controls

   Choose the controls that fit, record the reasons, and cover the AI life cycle: data, development, testing, deployment and monitoring.

6. Operate with people in the loop

   Human oversight where it matters, monitoring of what the system really does, and handling of incidents and complaints.

7. Audit and review

   An internal audit and a management review, then a certification audit by an accredited body, with surveillance audits after.

Where AI and automation help

• Keeping the AI inventory current by reading what is actually deployed, and flagging uses nobody registered.
• Collecting monitoring evidence on a schedule: performance, drift, human overrides.
• Drafting impact assessments for a person to review and approve.

Traps that cost the most time

• Writing one policy and calling it done.
• Missing the AI that arrives inside suppliers' products.
• Treating impact assessment as a form instead of a conversation with the people affected.

Certification to ISO/IEC 42001 does not by itself show conformity with the EU AI Act, which is a law with its own requirements.

ISO/IEC 42001 (ISO)↗ NIST AI Risk Management Framework↗ More in the library

The road to the EU AI Act

Use it when you build, provide or use AI systems and the law may apply to you. The EU AI Act is a law, not a standard: obligations depend on your role and on how risky your AI systems are. The first question is which category applies to you.

1. Find your role

   Provider, deployer, importer, distributor or authorised representative. Duties depend on which you are, and you can be more than one.

2. Inventory your AI systems

   Every system and use, including those you buy and those built into other tools.

3. Classify the risk

   Prohibited practices (already in force), high-risk systems, systems with transparency duties, and the rest. The category decides what follows.

4. Provider duties for high-risk systems

   Risk management, data governance, technical documentation, logging, transparency to users, human oversight, accuracy and robustness, and a quality management system. Providers of general-purpose AI models have their own duties.

5. Deployer duties

   Use the system as instructed, give human oversight to competent people, monitor it, keep logs and tell the people affected. Some deployers must also assess the effect on fundamental rights. Systems that talk to people or generate synthetic content carry transparency duties.

6. Prove it

   For most high-risk systems the provider assesses conformity itself; a notified body is involved only for some. Register where required and keep documentation an authority could read.

7. Build AI literacy

   This duty already applies: people who work with AI need enough understanding to do it responsibly.

8. Monitor after launch

   Watch the system in use, report serious incidents, and update the file when the system or the law changes.

Where AI and automation help

• Keeping the inventory and classification current, with a person confirming each decision.
• Collecting logs and monitoring evidence so the technical file builds itself.
• Tracking which obligations apply from which date, and to which systems.

Traps that cost the most time

• Classifying by hope instead of by the text.
• Forgetting that using someone else's AI still makes you a deployer with duties.
• Treating it as a one-off project when the duties continue after launch.

General guidance, not legal advice. The Act entered into force in August 2024. As I understand the schedule, the prohibitions and the AI literacy duty have applied since February 2025, the rules for general-purpose AI models since August 2025, and the dates for the high-risk rules depend on the type of system and may be amended. Check the official text and any amendments for the dates that apply to you today.

EU AI Act, official text↗ Independent searchable guide↗ More in the library

Doing several without doing it twice

The roads share most of their ground. Build controls and evidence once, map them to every framework you need, and let each audit read the same records.

• One control record linked to every requirement it answers, across SOC 2, ISO 27001, ISO/IEC 42001 and the AI Act.
• One evidence trail for every audit.
• One risk register that explains why each control exists.

Want help choosing or starting a road? Work with me → Read: compliance as a graph → Back to the AI World →