ISO 27001:2022 Annex A 5.15 Access control for AI Companies

ISO 27001 Annex A 5.15 Access Control is a security control that mandates organizations to establish rules for restricting logical and physical access to information assets. For AI companies, this control is essential to prevent unauthorized modification of model weights and training data, ensuring that intellectual property remains secure against insider threats and external compromises.

For a fast-moving AI organisation, compliance frameworks often appear as business decelerators. This guide reframes ISO 27001 Annex A 5.15 Access Control not as a hurdle, but as the foundational framework for building the operational resilience and market trust that accelerate growth. In an industry where data is your most valuable asset and algorithmic integrity is paramount, demonstrating robust control over who can access what is a powerful statement of your organisation’s maturity.

This guide is designed to help you, as an AI company, navigate this essential control. We will break down its core principles, explore the unique and high-stakes access control challenges you face, and provide a practical, step-by-step roadmap to achieve and maintain compliance without renting a generic SaaS platform.

The “No-BS” Translation: Decoding the Requirement

Let’s strip away the auditor jargon. Access Control isn’t about filling out forms; it’s about making sure your intern doesn’t have the power to delete your entire AWS production environment.

The Auditor’s View (ISO 27001)	The AI Company View (Reality)
“Rules to control physical and logical access to information and other associated assets shall be established, documented and implemented based on business and information security requirements.”	Stop giving everyone Admin access. 1. Just because they are a Senior Dev doesn’t mean they need Root access to the billing account. 2. Use AWS IAM Roles, not long-lived access keys. 3. If they leave the company, their access needs to die instantly, not “whenever HR emails IT.”

The Business Case: Why This Actually Matters for AI Companies

Why should a founder care about RBAC (Role-Based Access Control)? Because in the AI world, your valuation is tied to assets that are incredibly easy to steal or destroy if you leave the door open.

The Sales Angle

Enterprise clients are terrified of “Insider Threats.” In security questionnaires, they will ask: “Do you enforce the Principle of Least Privilege?” and “How do you segregate duties between development and production?”. If your answer is “We are a startup, everyone does everything,” you are a liability. If your answer is “We use a strict RBAC model with automated revocation and quarterly access reviews,” you look like a safe pair of hands.

The Risk Angle

The “Disgruntled Employee” Scenario: An engineer is fired. They still have their SSH keys to the model inference servers. In 5 minutes, they can delete the model weights or exfiltrate the training data to a competitor. Annex A 5.15 forces you to have the “Kill Switch” process ready before this happens.

DORA, NIS2 and AI Regulation: Access is Everything

Regulators know that “Identity is the new perimeter.” If you can’t control access, you can’t control risk.

• DORA (Article 9): Mandates that financial entities and their ICT providers (you) implement “strong authentication and access control mechanisms.” You must prove you restrict access to critical functions.
• NIS2 Directive: Requires “supply chain security.” If your developers have unrestricted access to your client’s environments, you are a supply chain risk. Access control limits the blast radius of a compromise.
• EU AI Act: High-risk AI systems require “Human Oversight.” This implies a strict hierarchy of who can authorise model deployment or override system outputs. A 5.15 provides the governance structure for this oversight.

ISO 27001 Toolkit vs SaaS Platforms: The Access Control Trap

SaaS platforms love to “monitor” your access, but they rarely help you design it. They give you a dashboard of red lights, but no strategy. Here is why the ISO 27001 Toolkit is the superior choice for building a lasting access architecture.

Feature	ISO 27001 Toolkit (Hightable.io)	Online SaaS Platform
Design vs Monitoring	Strategic Design. Our Access Control Policy helps you define roles (e.g., “ML Engineer,” “Data Scientist”) and map them to assets.	Alert Fatigue. The platform yells at you because “User X hasn’t logged in for 30 days” but doesn’t help you decide if User X should have access at all.
Ownership	You Own the Matrix. Your Access Control Matrix is a spreadsheet you control. It is your single source of truth.	Rented Logic. The “evidence” is locked inside their proprietary system. If you leave, you lose your audit trail of who had access when.
Simplicity	Clear Rules. “If you leave, we run this offboarding script.” Simple, documented, effective.	Complex Configuration. You spend hours configuring integrations with 50 different apps just to get a green tick.
Cost	One-off fee. Pay once. Manage access forever.	Per-User Pricing. As you hire more staff, the cost of “monitoring” their access goes up. You are penalised for growth.

Understanding the Foundations: What is Annex A 5.15 Access Control?

Most catastrophic security breaches and failed audits share a common origin: poorly managed access. Access control is where your organisation’s security policies move from theory to reality. It provides the operational proof of how seriously you take security.

Clear Ownership

Every asset, from a sensitive training dataset in a cloud bucket to a physical server room, must have a named owner. This individual is accountable for all access decisions related to that asset.

Least Privilege

This principle dictates that users should only be granted the absolute minimum level of access required to perform their specific duties. It prevents the accumulation of excessive permissions that can turn a minor incident into a major breach.

Full Lifecycle Management

Access control is not a one-time event; it is a continuous process. It starts with a formal request, continues through regular periodic reviews, and ends with immediate revocation when an individual changes roles or leaves.

The AI Challenge: Why Access Control is Different for You

While the principles of access control are universal, their application within the unique workflows of an AI company presents distinct challenges.

Securing Sensitive Training Datasets

A critical risk here is “orphaned access,” where former data scientists retain active credentials to cloud storage environments (like S3 buckets) long after their projects are complete. Similarly, “permissions drift” poses a constant threat; temporary access granted for a specific research project can easily become a permanent vulnerability.

Protecting Algorithmic Processes and Models

The integrity of your AI models is a core business asset. Poor separation of duties can allow a single individual to request, approve, and implement changes to source code or system configurations without any oversight. This creates an unacceptable risk of both accidental and malicious disruption.

Managing Vulnerabilities in the AI Supply Chain

Modern AI development relies on a complex supply chain of third-party cloud services and data annotation partners. Without a robust process for managing third-party access, a temporary permission granted to an external supplier can become a permanent backdoor into your network.

A Practical Roadmap: Your Steps to Compliant Access Control

Achieving auditable compliance is about embedding a systematic process into your daily operations. This roadmap provides a clear guide.

• Document Your Policy: Create a formal policy that serves as the single source of truth for access control.
• Define Ownership: Assign a specific, named owner to each asset who is responsible for authorising access.
• Formal Request Workflow: Implement a structured workflow where every request includes a business justification and requires approval.
• Automate Revocation: Link your access control system with HR to ensure access is revoked immediately when an employee leaves.
• Regular Access Reviews: Schedule periodic reviews (e.g., quarterly) to re-certify that permissions are still required.

The Evidence Locker: What the Auditor Needs to See

When the auditor calls, you need proof. Do not show them a blank face. Show them these files:

• Access Control Policy (PDF): Signed, dated, and reviewed within the last 12 months.
• Access Matrix (Excel): A clear grid showing Role (e.g., “Junior Dev”) vs Asset (e.g., “Production DB”). Cells should say “Read,” “Write,” or “None.”
• New User Ticket (Linear/Jira): A sample ticket showing a new hire request, the Manager’s approval, and the IT team’s completion note.
• Leaver Log (CSV): A log showing users who left and the exact timestamp their access was cut.
• Access Review Report (PDF): Evidence that you looked at who has Admin access and confirmed it is still necessary.

Common Pitfalls & Auditor Traps

Here are the top 3 ways AI companies fail this control during a Stage 2 Audit:

• The “Founder’s God Mode”: The CTO still has direct root access to everything “just in case.” Auditors hate this. Even the CTO should use a named account with specific privileges, elevating only when necessary (sudo).
• The “Zombie” Contractor: A data labeler left 6 months ago, but their AWS IAM user is still active because “they might come back.” This is a Major Non-Conformity.
• The “Shared API Key”: The entire Data Science team shares one admin API key for OpenAI. If one person leaks it, you have to rotate it for everyone, breaking production. Each user/service needs their own identity.

Handling Exceptions: The “Break Glass” Protocol

Sometimes, the rules get in the way of fixing a burning server. You need a protocol for breaking the rules safely.

The Emergency Access Workflow:

• Trigger: P0 Incident where standard access is insufficient.
• Action: Engineer accesses the “Break Glass” account (e.g., AWS Root MFA token stored in a physical safe or secure vault).
• Notification: An automated alert is sent to the CISO and CEO immediately.
• Audit: Post-incident review must account for every command executed while in “Break Glass” mode. Credentials are rotated immediately after.

The Process Layer: “The Standard Operating Procedure (SOP)”

How to operationalise A 5.15 using your existing stack (Google Workspace, AWS, Linear).

• Step 1: Request (Manual). Hiring Manager creates a “New Hire” ticket in Linear. They select the “Role” from a dropdown (mapped to your Access Matrix).
• Step 2: Approval (Manual). Security/IT Lead approves the ticket. (No approval, no access).
• Step 3: Provisioning (Automated). IT adds the user to the specific Google Workspace Group (e.g., group-engineering).
• Step 4: Sync (Automated). AWS SSO syncs with Google Workspace. The user automatically gets the correct AWS IAM Role (e.g., ViewOnly for Junior Devs) based on their group.
• Step 5: Review (Manual). Quarterly, the Security Lead exports the Google Group members list and asks the Manager: “Do these people still work here?”

By embracing a solution like Hightable.io, you can embed this discipline deep into your company’s DNA. This transforms a complex compliance requirement into a lasting business asset – one that safeguards your innovations, accelerates revenue, and builds enduring trust with customers and investors alike.

ISO 27001 Annex A 5.15 for AI Companies FAQ

About the author