UK API Security Compliance Requirements

API security in the UK isn’t governed by a single, dedicated law. Instead, you must secure application programming interfaces in the context of broader cybersecurity, data protection, and resilience obligations, such as the UK General Data Protection Regulation (UK GDPR), Network and Information Systems (NIS) Regulations 2018, and Telecommunications (Security) Act 2021 (TSA).

This article guides you through the key API security compliance requirements in England and the UK. By the end of it, you’ll know where to find the most relevant information, and you’ll have concrete examples of how to address critical compliance obligations.

The Complex UK API Compliance Ecosystem

This section provides a comprehensive list of UK API compliance requirements. It draws on broader public and industry standards, as well as the legislative corpus. Since regulations often overlap and interact, we’ve grouped them by the sector or data type they address.

However, keep in mind that comprehensive is not the same as exhaustive. No list of API security requirements can be complete and finite because of two dynamic factors:

• Contractual obligations: Every supplier contract, especially in large enterprises, can include unique API security clauses—such as specific encryption ciphers, mandated pentesting frequency, or data-handling protocols—that go beyond standard requirements.
• Evolving technology and regulation: New technologies, such as APIs in AI applications, introduce unprecedented risks. They may lead to novel, sometimes temporary, compliance demands or future UK AI legislation that mandates new security controls.

Still, our list covers all the major legal and industry compliance requirements for APIs in the UK, which makes it invaluable for practical implementation and auditing.

1. Foundational Data Protection and Security

These requirements apply to practically all foreign organizations operating in the United Kingdom, as well as UK-based organizations.

• UK GDPR / Data Protection Act (DPA) 2018: Applies to all organizations with APIs that touch the personal data of UK citizens. Requires data protection by design and default (through, say, techniques like pseudonymization and minimal data exposure), lawful bases for processing, explicit consent, and data subject rights (like the right to data access and portability, often fulfilled via APIs).

  The Information Commissioner’s Office (ICO) is the UK’s supervisory authority for enforcing the UK GDPR and Data Protection Act 2018 and may issue fines or enforcement notices for non-compliance.

• NIS Regulations 2018: Applies to operators of essential services (OES), such as utilities and health, and relevant digital service providers (RDSPs), like cloud services and search engines. Requires OES and RDSPs to put into practice security measures suitable for their network and information systems, including APIs, and to report any security incidents.

  The UK government is reviewing the NIS framework to align it with the principles of the EU’s NIS2 Directive. Updated UK NIS Regulations are expected by 2026, potentially expanding the definition of essential and digital services.

• Product Security and Telecommunications Infrastructure (PSTI) Act 2022: Applies to connectable products like IoTs and their associated services—like mobile apps, cloud storage, and APIs. In force since 29 April 2024, it mandates three baseline requirements: no default passwords, a public vulnerability disclosure policy, and a published minimum support period for security updates.

• Cyber Essentials/Plus: UK Government-backed scheme often mandated by government contracts. Requires fundamental controls on firewalls and (API) gateways, secure configuration, access control, malware protection, and patch management. Recognized under UK government procurement policy (PPN 09/14).

2. Financial Services

These requirements apply to financial institutions and to any third parties that access customer account data via an API.

• Payment Services Regulations (PSRs) 2017: Transposed PSD2 (EU) into UK law. Governs payment services and requires secure communication for all payment APIs.

• UK-onshored Strong Customer Authentication and Common and Secure Communication (SCA-RTS): Enforces the strong customer authentication (SCA) requirement on payment and account APIs. Requires customers to use at least two independent authentication factors when accessing accounts or initiating electronic payments.

• Open Banking Implementation Entity (OBIE) Standards / CMA Order: Demanded by the Competition and Markets Authority (CMA) for the CMA9 banks. Defines the technical API specifications and security profiles—say FAPI, OAuth 2.0, or OpenID Connect—that must be used to guarantee secure, standardized data sharing and payment initiation.

  Since September 2024, responsibility for maintaining and developing Open Banking standards has moved from the Open Banking Implementation Entity (OBIE) to Open Banking Limited (OBL).

• Payment Card Industry Data Security Standard (PCI DSS): Applies to any organization, no matter the industry, that stores, processes, or transmits cardholder data. All APIs working with payment card details must comply with the 12 core requirements, including encryption, access control, and network segmentation. The current version is PCI DSS v4.0.1 (effective January 2025).

3. Public Sector and Government Digital Services

These standards are mandatory for APIs built for or consumed by UK government departments, agencies, and public services.

• GDS Design Manual and Standards: All public sector digital services, including APIs, must adhere to the Technology Code of Practice. That means using HTTPS/TLS 1.3 where supported (minimum 1.2), adopting a RESTful design where appropriate, and applying government security guidelines like those from NCSC. GDS now references the NCSC API Security Guidance (2025) as best practice.

• National Cyber Security Centre (NCSC) Guidance: NCSC guidance is the de facto technical standard for UK public sector API security and is often referenced in policies. As of April 2025, the NCSC’s Securing HTTP-based APIs collection provides detailed guidance on authentication, threat modelling, testing, and API life cycle security.

• Public Services Network Code of Connection (PSN CoCo): If an API connects to the PSN network, it must adhere to the CoCo and CoICo for secure inter-government connectivity and data exchange. However, note that the PSN is being retired; new services should follow the Internet First policy and the NCSC Cloud Security Principles instead, as CoCo/CoICo applies only to legacy PSN connections.

4. Health and Social Care

APIs that handle patient health records, especially within the NHS ecosystem, are subject to stringent clinical-grade requirements.

• Data Security and Protection Toolkit (DSPT): The DSPT is a mandatory annual self-assessment for any organization accessing NHS patient data. It requires specific API security controls covering people, process, and technology, including the Caldicott Principles for protecting confidential patient information.

• DCB0129/DCB0160 (Clinical Safety Standards): Mandatory for developers (DCB0129) and implementers (DCB0160) of health IT systems. Requires a Clinical Safety Officer (CSO) and a documented clinical-risk-management plan for APIs that impact patient care or medical decisions.

• Fast Healthcare Interoperability Resources (FHIR) UK Core: APIs exchanging health data must use the FHIR standard, aligned to the UK Core profile, to ensure semantic and technical interoperability. The FHIR UK Core v4.0.0 is current as of 2025.

5. Global Best Practices and Contractual Standards

These requirements are not always legal statutes. Still, they are mandatory for most large UK enterprises, are almost universally required by auditors, or are mandated through contractual terms.

• ISO/IEC 27001: A voluntary, though widely adopted, framework for information security management systems (ISMS). Its Annex A—e.g., ‘A.14 – System Acquisition, Development and Maintenance’—requires organizations to integrate information security controls (including secure development practices and testing) in system acquisition, development, and maintenance, which applies to APIs as well.

• OWASP API Security Top 10 (2023): Not a legal document, but still the recognized benchmark for API vulnerability assessment. Hence, compliance with the latest edition is routinely demanded.

• Contractual requirements: APIs supplied to large organizations must meet the client’s internal security policies, which typically reference standards such as ISO 27001 and NIST CSF, or require penetration testing before deployment.

6. Cross-Sector and Context-Specific Requirements

These requirements apply to multiple industries or in concrete operational contexts. They complement the legal and industry standards already listed by addressing ethical, archival, accessibility, and export control considerations that may affect API design, deployment, and governance.

• Data Ethics Framework (GDS): APIs handling large datasets or using AI/ML in the public sector must follow ethical standards, making sure that the API design avoids bias and provides transparent access to data processing decisions.

• The National Archives (TNA) requirements: APIs handling public records or sensitive government data must meet the TNA standards for data retention, transfer, and deletion to guarantee records are preserved or destroyed legally.

• Equality Act 2010 / WCAG 2.1 AA: APIs that directly support public services must adopt accessibility standards by providing necessary metadata, reliable error handling, and structured data formats.

  In practice, these obligations arise under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, which require WCAG 2.1 AA compliance for public-facing digital services (developer portals, UIs, and documentation).

• Export control regulations: APIs that export certain types of sensitive technology or cryptographic software may be subject to UK export licensing under the Export Control Order 2008 (Schedule 2, Group 4 – Cryptographic Items).

• Telecommunications Security Act 2021 and Electronic Communications (Security Measures) Regulations 2022: For telecoms operators and network providers, these two instruments work together to define mandatory security and resilience requirements, including controls relevant to API and interface security.

How Equixly Makes Compliance Happen

Equixly is an AI-fueled API security testing platform. In OWASP’s classification, the platform covers two (of the three) principal API security categories: “API Security Testing” and “API Security Posture.”

Equixly shines at

• Identifying business logic vulnerabilities
• Continuous, scalable testing of endpoints
• CI/CD pipeline integration
• Agent-automated offensive security testing
• Shadow API discovery
• Data classification

The following table shows where Equixly adds value, facilitating the compliance efforts of UK organizations as well as those operating in this territory.

Equixly Compliance Mapping for UK API Security
Compliance Area	Control/Requirement	How Equixly Helps
1. Governance, Risk, and Compliance	API risk assessment and inventory	Can discover shadow APIs during testing. But a full risk register and governance must still be managed via your ISMS.
	Supplier / third-party API assessment	Can test partner APIs (if authorized), but vendor assurance and contractual oversight are still required.
	ISMS integration (policy, evidence)	The reports can be used as audit evidence for ISO 27001 “Annex A.12/A.14,” but policy management remains manual.
2. Authentication and Authorization	Strong authentication enforcement	Tests for weak or broken auth flows, such as missing tokens, weak key enforcement, or BOLA.
	Granular authorization / least privilege	Can identify privilege escalation or excessive data exposure, like BFLA.
	Key and token management	Tests whether APIs mishandle tokens or keys; however, life cycle / key vault management must be handled separately.
3. Encryption and Data Protection	Encryption in transit (TLS 1.2+)	Automatically checks for insecure protocols or missing HTTPS (GDS and GDPR compliance).
	Data minimization	Tests can reveal overexposed data fields (PII leakage). But design-level minimization remains a development responsibility.
4. Input Validation and Output Encoding	Schema validation	Tests input validation weaknesses, like missing schema enforcement and excessive input.
	Injection/parsing flaws	Detects injection vulnerabilities, such as SQLi, command injection, and JSON parsing.
	Output encoding (XSS, data leakage)	Detects common output-based vulnerabilities, but full context-aware encoding still requires developer enforcement.
5. Logging, Monitoring, and Incident Response	Incident response and breach notification	Helps reduce breach risk and provides preemptive evidence. However, response planning and ICO reporting remain manual processes.
6. API Life Cycle and Development	Secure coding practices	Integrates into CI/CD pipelines, scanning endpoints automatically. Supports NCSC secure SDLC recommendations.
	Testing and assurance	Automated dynamic testing (DAST) and logic testing—supports ISO 27001 A.14 controls and NIS risk management.
	Change management evidence	The reports can be attached to change records as proof of testing before release.
7. Rate Limiting and Abuse Prevention	DDoS/throttling testing	Can simulate Can simulate unbounded requests and batched queries to test API resilience.
	Rate limiting enforcement	Detects missing or weak rate limits, such as lack of 429 responses.
8. Documentation and Transparency	API documentation accuracy	Can highlight undocumented APIs, but documentation governance remains manual.
	Change tracking/audit evidence	Reports provide evidence but must be integrated into formal audit trails.
9. Optional Certifications and Standards	ISO 27001 / ISO 27701 support	Supports technical control validation but doesn’t handle policy management.
	Cyber Essentials / Plus	Demonstrates testing and patching against known vulnerabilities, aligning with Cyber Essentials’ secure configuration and vulnerability management requirements.
	OWASP API Security Top 10 compliance	Equixly’s detection coverage directly aligns with OWASP API Top 10 categories.
10. Sector-Specific Applications	Finance (PSD2 / FCA SCA)	Supports testing of SCA / CSC API interfaces, ensuring security of transaction endpoints.
	Telecoms (Telecoms Security Act 2021)	Can test telecom APIs for security flaws but doesn’t manage resilience or vendor reporting obligations.
	Healthcare (DSPT/NHS)	Technical vulnerability testing fits DSPT’s technical security testing control, but data governance is still needed.
	Critical Infrastructure (NIS)	Supports technical and organizational measures testing for NIS compliance. However, full risk governance is still required.

Equixly: Practical Use Cases for UK Companies

Here are some example scenarios of how a UK-based company might deploy Equixly to meet API compliance obligations:

• A financial services firm regulated by the FCA has open banking APIs. It uses Equixly to automatically test all new API endpoints for broken authentication or privilege escalation. That helps meet regulatory expectations around secure APIs (such as under PSD2/RTS) and provides evidence for UK GDPR controls.

• A public sector body must publish APIs in compliance with the GDS “API technical and data standards,” which include measures such as TLS, input schema, CORS, and versioning. It uses Equixly to continuously test its APIs and generate reports that demonstrate compliance with those standards.

• A telecoms supplier must meet obligations under the TSA 2021 and demonstrate resilience and secure interface endpoints. It deploys Equixly across its internal and partner APIs to identify risky endpoints, legacy versions, and shadow APIs, reducing the attack surface.

• A utility entity subject to the NIS Regulations 2018 uses Equixly as part of its broader cyber risk management. The platform acts as a continuous technical control that complements organizational measures like patching, network segmentation, and incident response.

Conclusion

In the United Kingdom, API security compliance requirements are not governed by a single law. From the UK GDPR and NIS Regulations to FCA and GDS, there is a whole matrix of data protection, cybersecurity, and sector-specific demands that organizations must meet to make sure their APIs are secure, resilient, and compliant.

Equixly supports your compliance efforts through its API security testing and posture capabilities. They enable you to find vulnerabilities, improve governance, and create audit-ready evidence so you can meet both regulatory and contractual obligations efficiently and confidently.

Get in touch to simplify API security and compliance.

FAQs

Is my organization legally required to comply with any specific UK API security law?

No, there’s no single API security law, but your APIs must comply with overlapping UK regulations, such as the UK GDPR, the NIS Regulations 2018, and sector-specific rules like PSD2 or the Telecommunications (Security) Act 2021.

How can my business demonstrate compliance with UK API security requirements in practice?

You can demonstrate compliance by maintaining evidence-based API security testing, documentation, and governance aligned with frameworks such as ISO 27001, Cyber Essentials, and NCSC guidance.

What’s the best way to keep up with evolving UK API compliance and security demands?

Adopt continuous compliance by automating security testing, monitoring regulatory updates, and integrating checks into your CI/CD pipelines.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.