Fintech Cloud Cost Control Under PCI DSS v4.0.1

A payments company does not get to decide freely how many environments it runs. PCI DSS, the card industry’s security standard, pushes teams toward separate, access-controlled pre-production estates, and every one of those estates is billed by the hour. This page covers the requirements that shape that footprint and how ZopNight fits inside them without weakening the controls an assessor will check.

The requirements that shape a fintech cloud estate

PCI DSS v4.0.1 is the only active version: the PCI Security Standards Council retired v4.0 on 31 December 2024, and v4.0.1 added or deleted no requirements. The clauses that bear most directly on environment sprawl:

• 6.5.3: pre-production environments are separated from production, and the separation is enforced with access controls.
• 6.5.4: roles and functions are separated between production and pre-production, so only reviewed and approved changes are deployed.
• 6.5.5: live card numbers (PANs) are not used in pre-production unless that environment is inside the cardholder data environment and fully protected.
• 7.2.4: all user accounts and their privileges are reviewed at least once every six months.
• 10.2.1.2: audit logs capture every action taken by anyone with administrative access.
• 10.5.1: audit log history is kept for at least 12 months, with the most recent three months immediately available.

The cost consequence is structural. Separation (6.5.3) and keeping live PANs out of test (6.5.5) push a payments team toward dedicated staging, sandbox and certification estates rather than one shared one. Each is billed around the clock, and none of them serves a customer.

Where ZopNight fits

ZopNight gives cost visibility, scheduling, recommendations and showback across AWS, GCP and Azure. For a PCI-scoped team the parts that matter are the ones that keep the separation intact:

• Scope access the way 6.5.3 and 6.5.4 expect. Custom roles scope each policy to specific resource IDs, and team members inherit their role’s policies only over the team’s assigned resources, so the staging team can schedule staging and nothing else. SAML sign-in is supported.
• Keep the read and write split explicit. A read-only cloud account gets discovery and recommendations; start, stop and remediation require read + write, and ZopNight blocks them server-side on a read-only account. That lets you connect production read-only and pre-production read + write.
• A record of every change the tool makes. ZopNight logs every mutating API request with its request and response body, state history records whether a schedule, an override or a named user caused each start or stop, and the audit log exports to CSV for evidence collection. This covers ZopNight’s own actions; it does not replace CDE logging under 10.2.1, and the 10.5.1 retention clock should run in your own log archive.
• Access reviews start from the cloud. Cloud IAM Import proposes users, groups and roles from AWS, GCP or Azure, and nothing is applied until an admin clicks Apply, which makes the six-month review in 7.2.4 a comparison rather than a rebuild.
• Policy in the pipeline. IaC governance evaluates Terraform or OpenTofu plans in the pull request, with builtin rules tagged to frameworks including PCI, and never runs apply.

Destructive remediations pass an admin-approval step before any cloud call. See how that works in approving destructive remediations, how scoping is set up in RBAC for cloud scheduling, and what the change log captures in the audit trail.

A practical order for a payments team

Connect production accounts read-only first, so discovery and recommendations cover the whole estate with no write path into the CDE. Put the certification and sandbox estates on schedules that match your testing calendar. When a certification run needs a box overnight, an override keeps it on for a set window, with a stated reason and an automatic expiry.