API Compliance: It’s About the Good Things You Do

API compliance means meeting API-relevant cybersecurity requirements set by regulatory and industry authorities.

Since there aren’t special requirements for APIs, to achieve API compliance, you must adhere to regulations and standards generally applicable to information systems, such as NIS2, DORA, GDPR, and PCI DSS.

This overview of API compliance will help you understand:

• Why compliance requirements apply to APIs, even though there aren’t separate API compliance requirements, and the existing regulations and standards almost never mention APIs
• What NIS2, DORA, GDPR, and PCI DSS have to do with APIs
• How to achieve API compliance

Why Must APIs Comply?

APIs make life easier. And that’s not a small beer. That’s why they’re in every nook and cranny.

Thanks to APIs, developers don’t have to reinvent the wheel every time they create a new app. APIs keep businesses data-driven and, hence, relevant and prosperous. They make open data exchange, interoperability, and integration of disparate systems possible. They enable innovation. They allow a better, fuller, and richer user experience.

So why not hack them? There’s no reason not to, especially considering the value of the data passing through them. Hackers know that, and we know that. They do a lot based on their knowledge; they act upon it. It’s a misdirected action, but it is an action.

Doing the right thing, on the other hand, is typically trickier than the opposite or just giving yourself over to inertia. To ensure that we, too, act upon our knowledge, regulatory bodies and industry authorities gather now and then to issue regulations and standards pertinent to cybersecurity. And that’s how compliance requirements come into existence.

Compliance requirements sometimes appear as an additional weight on the shoulders of already burdened security and development teams. However, they’re nothing but a formalized acknowledgment of what everyone must do to guarantee the security of their information systems and assets, including APIs.

The whole point of compliance is creating strong and resilient information environments and a culture of nurturing those qualities. Compliance requirements do not originate in a vacuum. They’re always a response to actual problems plaguing information systems in different industries.

For example, GDPR was not an abstract idea that someone came up with to burden organizations with strict, unnecessary rules. As personal information and privacy became terribly endangered online, the European Union decided to do something about it and protect user’s privacy.

APIs are integral to today’s information environments. No application or digital system can be imagined without a heavy reliance on them. As an illustration, 2023 State of API Security: A Global Study on the Reality of API Risk reported that the surveyed organizations relied upon as many as 501–2,500+ APIs.

These stats make it easy to see that strong and resilient information environments vastly hinge on strong and resilient APIs. And strong and resilient APIs are compliant APIs.

How to Achieve API Compliance with NIS2, DORA, GDPR, and PCI DSS

A complete list of cybersecurity-relevant standards and regulations would be long and unreadable. We’ll limit our overview to the following four:

• NIS2
• DORA
• GDPR
• PCI DSS

The NIS2 Directive

“NIS” stands for “Network and Information Security,” and “2” shows that the second is the latest version of the directive.

NIS2 sets strict requirements for:

• Security risk management and mitigation
• Security incident management, response, and mitigation

The directive is an expected reaction to the insufficient cyber resilience of organizations in the European Union. It stems from the need for common, clearly defined, rigorous cybersecurity standards across the EU.

In that spirit, NIS2 makes big steps toward standardizing and improving security vulnerability management. As part of the initiative for coordinated risk and incident management, it introduces a European vulnerability database.

In addition, the directive highlights the significance of supply chain security by laying down risk assessment requirements for critical supply chains.

What this implies for API compliance is that you need to build an API vulnerability management program that’s viable in the long term. It must include techniques for finding and addressing API vulnerabilities stemming from your API’s unique business logic, as well as tried-and-true methods for discovering and remediating the OWASP Top 10 API Security Risks.

Also, considering that insecure APIs are the weak link in supply chains, you must strive to inventory as many of the APIs you use as possible, including third-party APIs.

A real-life example of the effects of insecure APIs in supply chains is the infamous Sandworm cyberattack on Ukraine’s power grid in 2022, which resulted in a blackout. Its success was possible because of a vulnerable API in a third-party MicroSCADA control system the utility company relied upon.

NIS2 applies to most industries in the EU, from healthcare to banking to manufacturing.

Note that non-EU organizations are not exempt from the NIS2 requirements as long as they operate on the EU’s territory.

The directive entered into force on 16 January 2023 and has 17 October 2024 as an implementation deadline.

The DORA Regulation

DORA is short for “Digital Operational Resilience Act.” It’s an industry-specific EU regulation concerning ICT (information and communications technology) risk management in the finance industry.

Like NIS2, DORA arises from the necessity for coordinated and consolidated cybersecurity risk and incident management by the EU member states. Unlike NIS2, it applies only to financial organizations and entities, such as banks, crypto service providers, and insurance companies.

Again, like NIS2, DORA stresses the importance of supply chain security—third-party ICT providers—for the overall digital operational resilience of finance. This emphasis on supply chain security in recent EU regulations marks a shift (for the better) in regulators’ efforts to identify and address critical entry points for cyberattacks, including third-party APIs.

The regulation also underlines the need for regular and frequent digital operational resilience testing, from end-to-end testing to vulnerability assessment and scanning to penetration testing.

In the API compliance context, that means integrating security testing into the SDLC (software development life cycle) and employing a wide range of software and security testing types, including automated penetration testing.

DORA entered into force on the same date as NIS2, that is, 16 January 2023. The implementation date is 17 January 2025.

It’s worth noting that an industry-specific regulation like DORA has precedence over general-purpose security compliance requirements such as NIS2. That implies that in subject matters where the two overlap, financial entities must follow DORA.

However, that doesn’t mean that financial entities are not also subject to NIS2. Since NIS2 is broader in scope, it regulates issues that DORA does not cover. Hence, it may happen that some financial entities, such as large significant banks, must adhere to both directives.

The GDPR Law

GDPR (General Data Protection Regulation) is an EU data privacy and security law that applies to all organizations processing personal data of EU citizens and residents. Hence, it applies to non-EU organizations with a user base in the EU as much as to those that are EU-based.

GDPR defines data processing and describes the rights of data subjects and the obligations of data controllers and data processors regarding personal data processing.

The processing of personal data is lawful only if:

• Data subjects give explicit consent, which they can withdraw at any time.
• It’s for specific, clearly stated purposes.
• It’s necessary for contractual or legal purposes, or it’s in the legitimate interest of the person, public, data controller, or a third party (in the latter two cases, unless this interest conflicts with the rights and freedoms of protected data subjects such as children).

The law emphasizes the sanctity of data integrity and confidentiality and the accountability of organizations processing data. The accountability requirement includes proving compliance with GDPR through detailed documentation and similar mechanisms.

In API compliance terms, this requires generating security reports that:

• Provide evidence for strong API security measures in place
• Show that you’re actively addressing any vulnerabilities, flaws, and bugs found in your APIs
• Indicate that you’re continuously monitoring your APIs, thwarting possible cyberattacks in your live environment

One of GDPR’s most important aspects is its emphasis on organizations implementing personal data protection by design and by default. That means that you must incorporate data security from the earliest phase of product or service development.

Since data transmission is one of the main reasons APIs exist, and insecure APIs are notorious for exposing sensitive user and company data, developers must interweave data security into API development, that is, take care of it before an API reaches the production phase.

This approach of incorporating security in API development is increasingly gaining ground as organizations realize that it’s cheaper, easier, and, overall, better to avoid security gaps in development than to cure them in production and live environments.

GDPR entered into force on 24 May 2016 and came into effect on 25 May 2018.

The PCI DSS 4.0 Standard

PCI DSS 4.0 (Payment Card Industry Data Security Standard) is the latest version of global requirements concerning the secure use of payment cards and data.

The PCI DSS requirements are issued by PCI SSC (Payment Card Industry Security Standards Council), which consists of representatives of the biggest payment brands, such as MasterCard, Visa, and American Express. Thus, PCI DSS is not a law. However, it’s nonetheless mandatory for all entities that:

• Store, process, or transmit cardholder data
• Operate with payment-related sensitive authentication data
• Affect the security of the cardholder data environment

Examples of such entities are merchants, payment processors, and card issuers.

Two particularly interesting PCI DSS requirements are:

• Requirement 6: Develop and Maintain Secure Systems and Software
• Requirement 11: Test Security of Systems and Networks Regularly

Combined and put in the API compliance context, they require:

• API development in line with secure coding guidelines and security best practices
• Review of the API code to identify vulnerabilities
• Regular vulnerability scanning and testing
• Remediation of discovered security vulnerabilities but also rescanning and retesting to make sure they’re no longer there

In addition, API compliance with PCI DSS requires precise data classification so you know which endpoints work with sensitive data, such as credit card numbers and payment details, which is part of API posture management.

PCI DSS was published on 31 March 2022 and became mandatory on 1 April 2024.

Conclusion

APIs have become pivotal in modern information environments. Therefore, compliance requirements like NIS2, DORA, GDPR, and PCI DSS directly apply to APIs.

To achieve API compliance, you must:

• Integrate security into API development
• Perform regular API security testing
• Inventory the APIs you use
• Do data classification
• Build a viable long-term vulnerability management program

Get in touch with us to learn how Equixly alleviates your compliance stress and helps you achieve API compliance.

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

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.