Ema Achieves PCI DSS 4.0.1 Compliance: What It Means for You

PCI DSS compliance is one of the most demanding security benchmarks in enterprise software, and one of the most meaningful signals of trust for any platform that touches financial data.

Ema is now PCI DSS 4.0.1 compliant.

Here is what that means, why it matters for your organisation, and how it fits into the compliance framework we have built around the platform.

Why PCI DSS 4.0.1, and Why Now

The Payment Card Industry Data Security Standard is a globally recognised security framework developed by the PCI Security Standards Council, established by Visa, Mastercard, American Express, Discover, and JCB. It defines the technical and operational requirements that any organisation storing, processing, or transmitting cardholder data must satisfy.

Version 4.0.1 is the latest revision, superseding PCI DSS 3.2.1, which reached end-of-life in March 2024. The update reflects a fundamental shift in philosophy: away from point-in-time compliance snapshots toward continuous, risk-based security. Key changes include stricter authentication requirements, targeted risk analysis for control customisation, expanded e-commerce and phishing protections, and more rigorous testing procedures across all 12 requirements.

For Ema, where enterprise customers deploy AI Employees across billing, finance, and customer operations workflows, PCI DSS compliance is not a commercial checkbox. It is a structural assurance that the controls protecting cardholder data are independently verified, continuously monitored, and built to hold under adversarial conditions.

How Ema Meets the 12 PCI DSS Requirements

PCI DSS 4.0.1 is organised into 12 core requirements across six control objectives. Here is how Ema's architecture maps to each.

Network Security Controls (Requirement 1)

Ema's network perimeter is anchored by Cloudflare Enterprise, providing Web Application Firewall protection, DDoS mitigation, bot management, and deep packet inspection at the edge. Internally, dedicated Virtual Private Clouds enforce network segmentation between environments. Istio service mesh enforces mutual TLS for all east-west service communication. Firewall rules are defined as code, version-controlled, and subject to change control review before any modification reaches production.

Secure Configurations (Requirement 2)

All infrastructure is provisioned via Terraform and Helm, with hardened baselines aligned to CIS Benchmarks Level 1 and 2. Configuration drift is continuously monitored through our Cloud-Native Application Protection Platform. No production system deploys without passing automated policy gates in CI/CD, which check for misconfigurations, insecure defaults, and exposed secrets before any code reaches a running environment.

Protecting Stored and Transmitted Data (Requirements 3 & 4)

Ema enforces AES-256 encryption at rest across all data stores and TLS 1.2+ in transit, with TLS 1.3 preferred wherever supported. Cardholder data minimisation is a design principle: our architecture reduces the volume of card data that traverses or is retained within the platform. Where PII and payment data must be handled, our automated redaction pipeline, powered by Google Cloud DLP, masks sensitive fields before they reach third-party LLM providers. Cardholder data never leaves our controlled environment unprotected.

Malicious Software and Secure Development (Requirements 5 & 6)

Ema's Secure Software Development Framework embeds security into every phase of the development lifecycle. Static Application Security Testing and Software Composition Analysis run on every pull request. Dynamic Application Security Testing and manual penetration testing happen quarterly and before every major release. Endpoint protection covers all corporate devices, managed via Kandji MDM with hardened macOS configurations and mandatory encryption.

Access Control (Requirements 7, 8 & 9)

Access at Ema is built on Zero Trust principles: no implicit trust, least privilege by default, and just-in-time elevation for privileged operations. Okta enforces phishing-resistant MFA across all production and administrative access. Role-Based Access Control is strictly enforced, with quarterly access reviews and automated deprovisioning on employee offboarding. Physical access controls are handled at the data centre level through GCP and Azure, both of which hold their own PCI DSS certifications.

Logging, Monitoring, and Testing (Requirements 10 & 11)

All access to in-scope systems is logged and centralised. Our SIEM platform aggregates, correlates, and alerts on anomalous behaviour in real time, with automated playbooks enabling rapid incident response. Penetration testing is conducted quarterly by accredited third parties, with findings tracked to remediation closure in our risk register. Vulnerability scans run continuously, with CVSS-based prioritisation and assigned SLAs for every finding.

Organisational Policies (Requirement 12)

PCI DSS compliance at Ema is not owned by a single team. It is embedded into how we operate. Security policies are codified, version-controlled, and reviewed annually or following material changes. All employees complete mandatory security awareness training at onboarding and annually thereafter. Our cross-functional Security and Governance Committee oversees risk, exceptions, and corrective actions, with named owners for every control.

What This Means for Ema Customers

PCI DSS compliance is not about Ema's internal controls alone. It is about what it enables for you.

Faster procurement and vendor approval. If your organisation operates in financial services, retail, or any sector handling card payments, Ema's PCI DSS 4.0.1 compliance means you can onboard us without requiring a bespoke security review to validate what is already independently assured.

Reduced supply chain risk. As an ICT provider operating under your data processing agreements, Ema's compliance directly strengthens your own PCI DSS posture. Our controls are designed to support your assessments, not complicate them.

Confidence in agentic workflows touching sensitive data. As you deploy Ema's AI Employees across finance, billing, and customer operations, the platform handling those workflows meets the highest standard of cardholder data protection.

Audit-ready evidence on demand. Our Trust Center at trust.ema.ai provides current certificates and compliance documentation. Deeper evidence, including penetration test executive summaries and control mappings, is available to qualified customers under NDA.

PCI DSS Within Ema's Unified Compliance Framework

PCI DSS 4.0.1 does not exist in isolation. It is one layer in a unified compliance framework spanning security, privacy, AI governance, and cloud controls, with each standard reinforcing the others.

This is not a collection of separate compliance programmes running in parallel. It is an Integrated Management System: one governing body, one evidence repository, one continuous monitoring programme, satisfying multiple frameworks simultaneously. When we close a PCI DSS finding, it closes across our risk register for every relevant control. When an ISO 27001 audit identifies a gap, it is assessed for PCI DSS impact before remediation is scoped.

The result: a compliance posture that is more durable, more auditable, and more operationally rigorous than anything built framework by framework.

Compliance Is a Product Feature

At Ema, trust is a product feature, not a compliance checkbox. Achieving PCI DSS 4.0.1 is proof that the controls protecting your most sensitive financial data have been independently verified, stress-tested, and built to hold.

PCI DSS 4.0.1 introduced a continuous assurance model because the threat landscape does not stand still. Neither do we. Our vulnerability management programme, penetration testing cadence, and continuous control monitoring ensure that our compliance posture reflects our actual security posture, not a point-in-time snapshot.

As we scale, adding new customers, new frameworks, and new agentic capabilities, our unified compliance framework scales with us. Every certification and every control we adopt strengthens the same foundation.

For current certificates, policies, and compliance documentation, visit our Trust Center at trust.ema.ai. For deeper evidence or framework-specific mapping requests, reach out to your Customer Success Manager.