Regulatory Compliance
The certifications API7.ai holds, the current FIPS 140-2 status of the shipped OpenSSL build, and pointers to the controls that implement the rest.
Data security and privacy are paramount for enterprises in the data-driven business environment. API gateways, which handle large volumes of sensitive data, must adhere to strict compliance standards to protect data during transmission and processing.
Global and regional regulations such as GDPR, FIPS 140-2, and SOC 2 set rigorous data management requirements to safeguard sensitive information. These regulations help mitigate the risks of data misuse or leakage, ensuring that business operations align with international security and privacy standards.
API7.ai prioritizes security and continuously maintains compliance across its products and services. API7.ai protects data by adhering to compliance standards including SOC 2 Type II, ISO/IEC 27001:2022, HIPAA, and GDPR. These compliance standards collectively address data protection and security's technical, operational, and regulatory aspects, making API7.ai a secure, compliant choice for organizations across sectors.
FIPS 140-2
FIPS 140-2 (Federal Information Processing Standard 140-2) is a US government security standard specifying cryptographic module requirements. Industries such as finance and healthcare often impose specific compliance requirements for data security.
The standard API7 Gateway data plane image ships a general-purpose OpenSSL build (OpenSSL 3.4.1 as of API7 Gateway 3.10.7) and does not load a FIPS-validated cryptographic provider by default: the image's OpenSSL modules directory does not contain a fips.so provider, and the FIPS configuration section in the bundled openssl.cnf is present but commented out. Encryption and decryption of SSL/TLS traffic on that image run through the standard, non-FIPS OpenSSL provider.
Do not treat the standard image as FIPS 140-2 validated. If your compliance program requires FIPS 140-2 validated cryptography, verify the OpenSSL build and provider status of the specific image you deploy, and contact the Trust Center to confirm whether a FIPS-enabled build or configuration is available for your use case before relying on it for an audit.
The controls behind the certifications
The rest of what an auditor asks about is implemented by features documented elsewhere. This page does not restate them:
| Control area | Where it is documented |
|---|---|
| Encryption in transit — TLS and mTLS on every hop | Mutual TLS between Control Plane and Data Plane, Client mTLS Authentication, Upstream mTLS |
Encryption at rest — data_encryption and keyring rotation | Security Hardening Reference |
| Authentication and network restriction | Security and Compliance Overview, IP Restrictions for Control Plane |
| Secret storage and external secret managers | Secure Credentials Management, Configure Secret Management |
| Data privacy — masking sensitive values in transit and in logs | Configure Data Masking |
| Access control and separation of duties | Role-Based Access Control, Permission Policies and Boundaries |
| Audit trail and retention | Audit Logs |
| Supply chain — image signing and vulnerability scanning | Verify Image Signatures, Vulnerability Scanning |
Related
- Trust Center — requesting the reports themselves.
- Open Source Licenses