API Security Governance: ISO 27001 Evidence for 2026

The API audit finding that arrives before the breach

Maria, the CISO of a rapidly scaling fintech SaaS company, opens an email from the lead auditor three weeks before the annual assessment. The message is direct:

“We will conduct a deep-dive review of your ICT third-party risk management framework and its alignment with DORA, NIS2 and GDPR, with a specific focus on your API ecosystem. Please provide the inventory, authentication model, rate limiting evidence and logging coverage for production and partner APIs.”

Two days later, internal audit sends a second message:

“We found 47 public API endpoints that are not in the asset inventory. Four accept API keys without rotation evidence. One partner integration has no rate limiting. Logging is inconsistent across production services. Please provide ISO 27001, GDPR and NIS2 evidence by Friday.”

There is no ransomware note. No public breach. No customer complaint. But the finding is serious because it exposes the governance gap attackers already exploit. APIs are now the real perimeter. They connect payments, onboarding, identity, customer portals, supplier services, mobile apps, cloud workloads, analytics platforms and outsourced risk engines.

A near-miss makes the issue harder to ignore. A junior developer, working under pressure, exposed a staging API to the internet with no authentication. It contained realistic, pseudonymized customer data. The red team found it first, but management asked the obvious question: what else is out there?

In 2026, API security governance is not only a developer checklist. CISOs, compliance leaders, internal auditors and boards must prove that APIs are known, owned, authenticated, monitored, rate limited, tested, risk assessed and included in incident reporting. The same evidence often needs to satisfy ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT-aligned assurance expectations.

Most organizations already own technical tools: API gateways, identity providers, SIEM platforms, WAFs, cloud logs, service meshes, CI/CD pipelines and ticketing systems. What they often lack is the control narrative. Which APIs are in scope? Who approves new APIs? Which logs prove authentication failures? Which register shows third-party API dependencies? Why are rate limits different for customer, admin and machine-to-machine APIs?

Clarysec’s approach is to treat API security governance as a cross-compliance evidence system, not as a one-off engineering activity. If an API can expose data, alter a business process, authenticate a user, trigger a payment, call a supplier or support a regulated service, it belongs in the ISMS evidence model.

Why API governance is now a board issue

NIS2 makes cybersecurity governance a management-body responsibility. Article 20 requires management bodies to approve cybersecurity risk-management measures, oversee implementation and receive training so they can understand cyber risks and their impact on services. Article 21 requires appropriate and proportionate technical, operational and organisational measures, including risk analysis, security policies, incident handling, business continuity, supply chain security, secure acquisition and development, vulnerability handling, effectiveness assessment, cyber hygiene, cryptography, access control, asset management and multi-factor or continuous authentication where appropriate.

For API governance, this means public APIs, partner APIs, admin APIs and internal microservice APIs may sit inside regulated service delivery. NIS2 can apply to cloud computing service providers, data centre service providers, content delivery networks, trust service providers, public electronic communications networks and services, and ICT service management providers such as MSPs and MSSPs, depending on sector, size, criticality and Member State classification.

DORA adds a financial-sector lens. It applies from 17 January 2025 and establishes uniform requirements for ICT risk management, ICT-related incident reporting, digital operational resilience testing, information sharing and ICT third-party risk management. Article 5 requires the management body to define, approve, oversee and remain responsible for the ICT risk management framework. Article 8 requires identification, classification and documentation of ICT-supported business functions, information assets, ICT assets, dependencies, third-party-supported processes, critical assets, inventories and legacy ICT risk.

In API terms, a payment initiation API, fraud scoring API, customer onboarding API or outsourced KYC API is not merely an endpoint. It is an ICT asset and dependency supporting a business function.

GDPR completes the picture. APIs that transmit identifiers, account data, device IDs, behavioural telemetry, biometrics, health-related data or financial profiles may process personal data. GDPR’s accountability principle requires controllers to demonstrate compliance with lawfulness, purpose limitation, data minimisation, storage limitation, integrity and confidentiality. Article 32 requires security of processing, while Articles 33 and 34 depend on reliable evidence when a personal data breach occurs.

The board does not need packet captures, but it does need confidence that the organization knows which APIs matter, what data they handle, which suppliers they depend on, how abuse is prevented, how incidents are detected and how compliance can be demonstrated.

Start with the API inventory

Most API failures begin as inventory failures. A deprecated mobile backend still runs in production. A temporary partner integration becomes permanent. A cloud function exposes a new endpoint. An internal API becomes internet reachable after a load balancer change. None of it appears in the CMDB, so none of it receives authentication review, logging standards, rate limit thresholds, supplier assessment or retention classification.

The first audit question is usually simple: “Can I see your inventory of APIs?”

Clarysec treats API inventory as part of the ISMS asset inventory. In the Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Controls in Action phase, Step 22, the guidance for ISO/IEC 27002:2022 control 5.9 explains:

“No organization can protect what it doesn’t know it has. Control 5.9 formalizes this foundational principle, requiring the establishment and maintenance of an up-to-date inventory of all information and associated assets relevant to the ISMS.”

The same step includes logical assets such as “user accounts, credentials, keys, software licenses, APIs” and service-related assets such as SaaS platforms and outsourced storage. The Zenith Blueprint calls the inventory “the central nervous system of your ISMS” because it informs access provisioning, encryption, backup, logging, classification and retention.

Clarysec’s enterprise Asset Management Policy Asset Management Policy turns this into a governance requirement:

“The IT Asset Manager must maintain a comprehensive and centralized asset inventory covering all information assets used by or connected to the organization.”

From section “Policy Implementation Requirements”, policy clause 6.1.1.

For SMEs, Clarysec’s Asset Management Policy - SME Asset Management Policy - SME explicitly includes API-relevant digital assets:

“Digital credentials and services: domain names, digital certificates, API keys, email accounts, cloud logins”

From section “Scope”, policy clause 2.2.4.

That phrase matters. In many audits, the API endpoint appears in a gateway, the token appears in a secrets vault, the certificate appears in a cloud account and the data flow appears in a privacy record. A defensible API inventory connects them.

In Zenith Controls: The Cross-Compliance Guide Zenith Controls, ISO/IEC 27002:2022 control 5.9, Inventory of information and other associated assets, is classified as a preventive control supporting confidentiality, integrity and availability. Its cybersecurity concept is Identify, its operational capability is Asset Management, and its security domains are Governance, Ecosystem and Protection. That helps auditors see API inventory as a preventive governance control, not administrative housekeeping.

Prove every API identity is intentional

Once the inventory exists, the next question is predictable: who or what can call these APIs?

Modern APIs authenticate human users, mobile apps, service accounts, CI/CD jobs, partner systems, workloads, bots, integrations, data pipelines and third-party platforms. Weak API keys, long-lived bearer tokens, missing mutual TLS, overprivileged OAuth scopes and hardcoded secrets all create audit exposure.

The Zenith Blueprint, Controls in Action phase, Step 19, addresses ISO/IEC 27002:2022 control 8.5, Secure authentication:

“Authentication is the first and most critical line of defense between a threat actor and your systems, data, and services. If authentication is weak, everything else, encryption, monitoring, segmentation, can be bypassed.”

The same step highlights machine-to-machine authentication. Keys, certificates and tokens must be protected rigorously, credentials should not be embedded in code, and secrets management or vaults should be used for secure storage and rotation.

Clarysec’s enterprise Application Security Requirements Policy Application Security Requirements Policy brings this directly into API governance:

“All application programming interfaces (APIs), microservices, and external integrations must be secured through:”

From section “Governance Requirements”, policy clause 5.3.

It then specifies:

“Enforcement of strong authentication, such as OAuth 2.0 and mutual TLS”

From section “Governance Requirements”, policy clause 5.3.1.

For smaller organizations, Clarysec’s Application Security Requirements Policy - SME Application Security Requirements Policy - SME provides the baseline:

“Authentication Controls: Applications must enforce strong authentication, including minimum password strength, account lockout after failed attempts, and session timeouts.”

From section “Policy Implementation Requirements”, policy clause 6.1.1.2.

For APIs, convert these requirements into an authentication evidence pack:

1. API inventory filtered by internet-facing, partner-facing, admin and internal APIs.
2. Authentication matrix showing OAuth 2.0, mTLS, signed requests, gateway authorizers or service mesh identity.
3. OAuth client and scope register with owner, purpose, expiry, approval and last review date.
4. Secrets management evidence showing storage, access, rotation and revocation.
5. Privileged API access review for admin endpoints and production service accounts.
6. Failed authentication logs and alert rules.
7. Test results for missing token, expired token, wrong audience, wrong scope and replay scenarios.

In Zenith Controls, ISO/IEC 27002:2022 control 8.5, Secure authentication, is mapped as a preventive control supporting confidentiality, integrity and availability. Its cybersecurity concept is Protect, its operational capability is Identity and access management, and its security domain is Protection.

NIS2 Article 21 supports this through access control, cryptography and multi-factor or continuous authentication where appropriate. DORA expects financial entities to maintain controls that protect authenticity, integrity, availability and confidentiality. GDPR Article 32 turns weak API authentication into a security-of-processing concern, especially where personal data is exposed.

Treat rate limiting as resilience evidence

Strong authentication is necessary, but not sufficient. An authenticated client can still abuse an API. Attackers use APIs for credential stuffing, enumeration, scraping, token spraying, password reset bombing, transaction abuse and denial of service.

Rate limiting used to be seen as a performance feature. In 2026, it is security, privacy and resilience evidence.

Clarysec’s Application Security Requirements Policy states:

“Rate limiting and abuse prevention”

From section “Governance Requirements”, policy clause 5.3.2.

The Zenith Blueprint, Controls in Action phase, Step 20, for ISO/IEC 27002:2022 control 8.26, Application security requirements, explains that application security requirements must be precise and actionable. It asks whether an application should be resilient to injection attacks, brute-force logins or denial-of-service attempts. It also gives the API-specific example that a new API should include access token validation and input sanitization, and notes that public-facing platforms may demand stricter validation, user behavior analytics and rate limiting.

A defensible rate limiting record should explain not only that throttling exists, but why thresholds were selected, who approved exceptions and how alerts are monitored.

For NIS2, this supports secure development, effectiveness assessment, business continuity and incident prevention. For DORA, rate limiting connects to ICT risk management, anomaly detection, resilience testing and continuity of critical or important functions. For GDPR, it supports data minimisation and protection against excessive or unlawful access, especially where API scraping could expose personal data.

Make logging the evidence layer

When an API incident occurs, the first real question is not “Do you have a SIEM?” It is “Can you reconstruct what happened?”

API logs should capture authentication failures, authorization denials, token claims, client identity, source, endpoint, method, request outcome, administrative changes, high-risk data access, rate limit events, abnormal volume, configuration changes and security-relevant errors. They must also avoid logging secrets, bearer tokens or unnecessary personal data.

The Zenith Blueprint, Controls in Action phase, Step 19, for ISO/IEC 27002:2022 control 8.15, Logging, states:

“Logging is the lifeblood of any secure IT environment. Without it, incidents remain invisible, accountability fades, and cause-and-effect relationships vanish into thin air.”

It also explains that logging is about traceability, and that useful logs must be securely stored, monitored, reviewed and protected against tampering.

Clarysec’s Application Security Requirements Policy - SME requires:

“Audit Logging: Applications must log authentication events (logins, logouts, and failed attempts), data access, and administrative changes.”

From section “Policy Implementation Requirements”, policy clause 6.1.1.7.

Clarysec’s Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME establishes the logging governance category:

“Required Log Types”

From section “Governance Requirements”, policy clause 5.4.

For cloud-hosted APIs, Clarysec’s enterprise Cloud Usage Policy Cloud Usage Policy reinforces the requirement:

“Logs must capture:”

From section “Policy Implementation Requirements”, policy clause 6.5.2.

In Zenith Controls, ISO/IEC 27002:2022 control 8.15, Logging, is mapped as a detective control supporting confidentiality, integrity and availability. Its cybersecurity concept is Detect, its operational capability is Information security event management, and its security domains are Protection and Defense. This makes logging the bridge between policy and proof.

NIS2 Article 23 requires staged significant-incident reporting: early warning within 24 hours of awareness, incident notification within 72 hours, intermediate reports if requested and a final report within one month after notification. For trust service providers affected in trust-service provision, notification within 24 hours of awareness is required.

DORA Articles 17 to 19 require ICT-related incident management with early warning indicators, severity and criticality classification, escalation, logging, root-cause follow-up and reporting of major ICT-related incidents through initial, intermediate and final reports. GDPR breach assessment also depends on logs to determine whether personal data was accessed, which individuals were affected and whether notification duties are triggered.

Build an API evidence pack in five working days

The goal of a rapid sprint is not to fix all API security in one week. The goal is to create a defensible baseline, identify gaps and begin risk treatment.

Day 1: establish the API register

Export routes from API gateways, service meshes, cloud load balancers, serverless functions, OpenAPI repositories and CI/CD deployment manifests. Normalize them into a single API register with endpoint, environment, owner, business process, data classification, personal data indicator, authentication method, rate limit, logging status, supplier dependency, criticality and last review date.

Use the Asset Management Policy clause 6.1.1 and Zenith Blueprint Step 22 as the governance anchor.

Day 2: classify authentication gaps

Create an authentication matrix. Flag APIs using static API keys, long-lived tokens, no audience validation, no scope validation, missing mTLS for partner integrations, shared service accounts or missing rotation evidence.

Map findings to Application Security Requirements Policy clause 5.3.1 and Zenith Blueprint Step 19. Record each gap as a risk with an owner, treatment path and target date.

Day 3: prove rate limiting and abuse controls

For public, partner and admin APIs, capture gateway policies, WAF rules, bot controls, quota settings and alert thresholds. Where controls are absent, record compensating controls or open risk treatment.

Use Application Security Requirements Policy clause 5.3.2 as the policy authority. For critical APIs, connect thresholds to service impact, customer harm and DORA or NIS2 resilience expectations.

Day 4: validate logging coverage

Sample logs for high-risk APIs. Confirm that logs capture successful authentication, failed authentication, authorization denial, data access, admin change, rate limit event, source identity and correlation ID. Verify time synchronization, retention, access control and tamper protection.

If logs contain tokens, secrets or excessive personal data, raise privacy and security remediation items.

Day 5: deliver the audit response pack

Deliver a concise evidence set:

• API inventory export and ownership summary.
• API risk register with treatment plan.
• Authentication matrix and token review evidence.
• Rate limiting evidence and approved exceptions.
• Logging coverage report and SIEM dashboard screenshots.
• Incident classification playbook for API abuse.
• Cross-compliance mapping to ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT-aligned audit views.

The important shift is that each artifact has a control story. The API register supports asset management. Authentication supports access control. Rate limits support application security and resilience. Logs support detection, incident response and accountability.

Cross-compliance mapping for API governance

The biggest mistake is building separate evidence sets for every framework. API governance works better as one control model with multiple regulatory views.

ISO/IEC 27001:2022 provides the management system that holds the evidence together. Clauses 4.1 to 4.4 require the organization to define ISMS context and scope, including interested parties, legal, regulatory and contractual obligations, and interfaces or dependencies with other organizations. Clauses 5.1 to 5.3 put accountability with top management. Clauses 6.1.1 to 6.1.3 create the risk assessment, risk treatment and Statement of Applicability process. Clause 8.1 requires operational planning and control, including control over externally provided processes, products or services relevant to the ISMS.

For API governance, this means a third-party payment API, cloud identity API or outsourced fraud detection API is not outside compliance because it is external. It is an interface and dependency that must be scoped, risk assessed and controlled.

NIST CSF 2.0 adds a useful executive view. Its GOVERN function helps organizations define stakeholder expectations, legal obligations, risk appetite and supply chain risk. Its Profiles approach supports a Current Profile, Target Profile, prioritized gap plan and continuous improvement cycle. That is exactly how an API governance sprint should operate.

COBIT 2019 can support the management lens by connecting API controls to governance objectives, control ownership, service continuity, security monitoring, risk reporting and issue tracking. The key is not to force APIs into a single framework, but to show that one evidence model answers multiple assurance questions.

How auditors test API governance

A strong program anticipates the auditor’s lens. The same evidence will be tested differently depending on the framework.

Clarysec recommends evidence triangulation. Do not show only the policy. Show the policy, implementation evidence and operating evidence.

For example:

• Policy: APIs must use OAuth 2.0 or mTLS where appropriate.
• Configuration: API gateway route shows JWT validation and allowed audience.
• Operating evidence: failed token attempts are logged and alerting is active.
• Review evidence: OAuth client review completed with owner sign-off.
• Risk evidence: a legacy API exception has compensating controls and a treatment deadline.

This is much stronger than a screenshot-only response.

Common API governance pitfalls

The most common issue is not that APIs are completely unsecured. It is that security is inconsistent.

One team uses OAuth scopes well, another uses a shared API key. One service logs data access, another logs only server errors. One partner integration has mTLS, another relies on a long-lived bearer token. Rate limits exist for public endpoints, but not for authenticated customer APIs where scraping can happen. The CMDB lists the application, but not its APIs, tokens, certificates, data categories or suppliers.

Recurring pitfalls include:

• Shadow APIs deployed through serverless functions or temporary test routes.
• API keys stored in CI/CD variables without documented rotation.
• Logging that captures tokens, secrets or unnecessary personal data.
• No correlation ID across gateway, application and database logs.
• Rate limit exceptions granted informally for large customers.
• Partner APIs missing contractual incident notification or audit rights.
• No API-specific incident classification for enumeration, scraping or token abuse.
• No mapping between API data flows and GDPR processing records.
• Security testing focused on the web UI while APIs remain untested.
• Board reports showing “application security” without API-specific risk metrics.

These are solvable problems, but only if the organization treats API governance as a managed control domain.

Turn API security into audit-ready governance

If your next audit asks for API security evidence, do not start by collecting random screenshots. Start with the control story.

Clarysec can help you build it with:

• Zenith Blueprint Zenith Blueprint to structure implementation across asset inventory, secure authentication, application security requirements and logging.
• Zenith Controls Zenith Controls to map ISO/IEC 27002:2022 controls such as 5.9, 8.5, 8.15 and 8.26 to cross-compliance expectations and audit perspectives.
• Clarysec policies including Asset Management Policy Asset Management Policy, Application Security Requirements Policy Application Security Requirements Policy, Cloud Usage Policy Cloud Usage Policy, Asset Management Policy - SME Asset Management Policy - SME, Application Security Requirements Policy - SME Application Security Requirements Policy - SME and Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME.

A practical next step is to run a Clarysec API Governance Evidence Sprint: inventory your APIs, classify authentication, verify rate limiting, validate logging, map third-party dependencies and produce an ISO 27001-ready evidence pack with NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT-aligned audit views.

APIs are where business logic, customer data and third-party dependencies meet. In 2026, they deserve more than technical protection. They need governance that can survive an audit, support a regulator response and help your teams detect abuse before customers do.