ISO 27001:2022 Annex A 5.18 Access rights for AI Companies

ISO 27001 Annex A 5.18 Access rights is a security control that requires organizations to manage the full lifecycle of access privileges, from initial provisioning to revocation. For AI companies, this control is critical to prevent unauthorized access to proprietary algorithms and training data, ensuring that permissions are regularly reviewed and aligned with the principle of least privilege.

While ISO 27001 provides a robust framework for information security, applying its controls to the unique environment of an Artificial Intelligence (AI) company requires a specialised focus. The pace of innovation, the nature of digital assets, and the collaborative workflows inherent in AI development present distinct challenges that standard compliance approaches may not fully address.

This guide provides a specific analysis of ISO 27001 Annex A 5.18 Access rights through the lens of an AI business. Effective access management is not merely a compliance checkbox; it is a strategic imperative for protecting your most valuable assets – proprietary training data, complex algorithms, and irreplaceable intellectual property. More than that, robust access control is a key enabler for building trust with enterprise clients, protecting valuation by securing IP, and achieving certifications like SOC 2 that are often prerequisites for major contracts.

The “No-BS” Translation: Decoding the Requirement

Let’s strip away the consultant-speak. Access Rights is about managing the lifecycle of permissions. It is the “Joiners, Movers, Leavers” (JML) process.

The Auditor’s View (ISO 27001)	The AI Company View (Reality)
“Access rights to information and other associated assets shall be provisioned, reviewed, modified and removed in accordance with the organisation’s topic-specific policy.”	The CRUD of Access. Create: Give new hires access on Day 1. Read/Update: Review their access when they get promoted. Delete: Kill their access the second they quit. If you mess this up, you have a ghost user.

The Business Case: Why This Actually Matters for AI Companies

Why should a founder care about “access reviews”? Because access creep kills security.

The Sales Angle

Enterprise clients will ask: “How often do you review user access rights?” If your answer is “Never,” you are telling them that a developer who left 2 years ago might still have access to their data. If your answer is “Quarterly, automated reviews with automated revocation for dormant accounts,” you prove you are running a tight ship.

The Risk Angle

The “Privilege Creep” Threat: A Junior Dev becomes a Senior Dev, then a Tech Lead. They accumulate permissions at every step but never lose the old ones. Eventually, they have “Super Admin” access by accident. If their account is compromised, the attacker has everything. Regular reviews strip away unnecessary rights.

DORA, NIS2 and AI Regulation: The Right to Access

Regulators demand strict control over who can touch critical systems.

• DORA (Article 9): Requires “sound administration of access rights.” You must grant access based on “need-to-know” and revoke it immediately upon termination. Delays are violations.
• NIS2 Directive: Mandates measures to “prevent unauthorized access.” If you don’t review rights, you can’t prevent unauthorized access by insiders who changed roles.
• EU AI Act: Requires human oversight. You must define who has the right to oversee the model. A 5.18 is how you document and manage those specific oversight rights.

ISO 27001 Toolkit vs SaaS Platforms: The Rights Trap

SaaS platforms are great at provisioning access (giving it), but terrible at deprovisioning logic. Here is why the ISO 27001 Toolkit is superior.

Feature	ISO 27001 Toolkit (Hightable.io)	Online SaaS Platform
Flexibility	Any System. Manage access rights for AWS, Slack, GitHub, and the physical office key card using one simple register.	Integration Limits. If the platform doesn’t integrate with your specific AI tool (e.g., Weights & Biases), it can’t track or revoke access, leaving a security hole.
Ownership	Your Log. You keep the “Access Review Log.” It proves you checked.	Black Box. You rely on their dashboard to tell you who has access. If their API sync breaks, you are blind.
Simplicity	Manager-Led. Send a spreadsheet to a manager: “Do these people still need access?” Simple.	Admin Overload. The platform spams the IT admin with 500 “access review” alerts that they just click “Approve All” on to make them go away.
Cost	One-off fee. Pay once. Manage rights forever.	Per-User Cost. You pay for every user you manage. Scaling your team scales your compliance bill.

Understanding the Foundations: What is Annex A Control 5.18?

At its core, Annex A control 5.18 is the organisational control responsible for governing the entire lifecycle of user access to information, systems, and associated assets. It establishes the rules for how access is provisioned, reviewed, and revoked.

Key Principles of Access Rights Management

Effective implementation is built on fundamental principles:

1. Authorisation: No access granted without explicit approval from the asset owner.
2. Segregation of Duties: The person requesting access should not be the one approving it.
3. Least Privilege: Users get the minimum access necessary.

The AI-Specific Challenge: Applying Control 5.18 to Your Unique Assets

AI companies manage assets that are fundamentally different from those in traditional businesses, creating distinct risks.

Protecting Sensitive Training Datasets

Unauthorised access to datasets can lead to theft or corruption (data poisoning). You must implement rigorous provisioning processes and conduct regular access reviews for data scientists and annotation teams.

Securing Algorithmic Processes and Models

Proprietary algorithms are the “crown jewels.” Improper access could lead to model theft or unauthorised modification. Applying role-based access controls is paramount.

Managing the AI Supply Chain

Modern AI development relies on third-party data sources and pre-trained models. Segregation of Duties is critical here. Manage access for all third parties by granting temporary rights with defined expiration dates.

A Practical Compliance Roadmap: Managing the User Access Lifecycle

To effectively implement control 5.18, establish a documented process for managing access rights throughout the user lifecycle.

Event	Trigger	Key Lifecycle Actions	Timeline
Joiner	Signed Contract	Provision Role-Based Access	Day 1
Mover	Role Change	Revoke old rights + Add new rights	< 48 Hours
Leaver	Termination	Immediate Disable (Kill Switch)	< 1 Hour
Review	Quarterly	Manager-Led Access Recertification	Every 90 Days

The Evidence Locker: What the Auditor Needs to See

When the audit comes, prepare these artifacts:

• Access Control Policy (PDF): A signed document defining how rights are granted and revoked.
• Access Request Tickets (Linear/Jira): Evidence of “Manager Approval” on a ticket before IT granted the rights.
• Revocation Log (CSV): A list of leavers and the timestamp their access was removed.
• Access Review Evidence (Email/PDF): An email chain or report showing managers confirming their team’s access is correct.

Common Pitfalls & Auditor Traps

Here are the top 3 ways AI companies fail this control:

• The “Rubber Stamp” Review: Managers click “Approve All” on access reviews without looking. The auditor catches this by asking a manager, “Why does this Junior Dev have Admin access?” If they don’t know, you fail.
• The “Mover” Gap: An employee moves from Engineering to Sales, but keeps their GitHub access. This violates “Least Privilege” and is a common oversight.
• The “Ad-Hoc” Grant: Access granted via Slack message (“Hey, can you let me into the DB?”) without a formal ticket. No ticket = no evidence.

Handling Exceptions: The “Break Glass” Protocol

Sometimes you need to grant rights immediately for an emergency.

The Emergency Grant Workflow:

• Action: Grant temporary Admin rights to resolve an incident.
• Constraint: Set an expiration (e.g., 4 hours).
• Review: Retroactive ticket created and reviewed by CISO the next day.

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

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

• Step 1: Request (Manual). Employee requests access via Linear ticket using a template.
• Step 2: Approval (Manual). Manager approves in Linear.
• Step 3: Provision (Automated). IT adds user to Google Group. SSO propagates access.
• Step 4: Review (Manual). Quarterly script generates a list of group members. Managers verify via Google Form.

By understanding the unique access-related risks to your training datasets and proprietary models, implementing a clear user access lifecycle process, and leveraging a dedicated solution like the High Table ISO 27001 Toolkit, you can build a secure and compliant environment.

ISO 27001:2022 Annex A 5.18 for AI Companies FAQ

About the author