How to Perform a PCI DSS Compliance Audit

A PCI DSS compliance audit examines how an organisation stores, processes, transmits and protects payment card data. It is more than a document review: the process combines interviews, evidence collection, technical testing and validation that security controls operate consistently across the cardholder data environment.

For Australian organisations, payment security must fit local operational and regulatory realities. A retailer in Melbourne, a bank in Sydney, a healthcare provider in Brisbane and an online marketplace serving regional customers may use different payment flows, cloud platforms and service providers. PCI DSS obligations also sit alongside the Privacy Act, the Notifiable Data Breaches scheme and, for APRA-regulated entities, expectations such as CPS 234.

Define the Cardholder Data Environment

Begin by establishing the audit scope. Identify every system, application, network segment, endpoint, payment terminal and third-party service that stores, processes or transmits cardholder data. Include e-commerce checkout pages, mobile applications, call-centre systems, point-of-sale devices and backup repositories.

Trace the movement of payment information from the moment a customer enters card details to authorisation, settlement, reporting and deletion. Tokenisation and hosted payment pages may reduce scope, but they do not remove the need to verify integrations, administrative access and supplier responsibilities.

Create a current asset inventory and data-flow diagram. Australian businesses should account for distributed operations, such as an Adelaide warehouse, a Sydney headquarters and cloud workloads hosted across several regions. Any undocumented connection can create a blind spot in the assessment.

Map Controls to PCI DSS Requirements

Use PCI DSS v4.0.1 as the control framework and map each applicable requirement to an owner, system and evidence source. The review should cover network security, secure configuration, vulnerability management, access control, authentication, logging, testing, incident response and security awareness.

Determine whether the organisation needs a Report on Compliance, Self-Assessment Questionnaire or Attestation of Compliance. The correct validation method depends on the merchant or service provider’s role, transaction channels and acquiring-bank requirements. Confirm expectations with the acquiring bank and payment brands before testing begins.

Translate every requirement into a testable audit procedure. For example, “restrict access to cardholder data” should become checks of role assignments, privileged accounts, approval records, access reviews and termination processes rather than a simple policy confirmation.

Gather Evidence and Interview Control Owners

Evidence should demonstrate that controls exist and operate over the required period. Request policies, procedures, network diagrams, firewall rules, vulnerability scans, penetration-test reports, training records, access reviews, change tickets, incident logs and contracts with service providers.

Interview IT administrators, security staff, developers, finance teams, help-desk personnel and business owners. Their explanations often reveal informal practices that written procedures omit. A staff member using spreadsheets to reconcile payments, for instance, may introduce card data into a system excluded from the original scope.

Useful evidence categories include:

• Approved security policies and annual review records
• Asset inventories, data-flow diagrams and segmentation rules
• User access listings, multifactor authentication records and joiner-mover-leaver tickets
• Vulnerability scans, penetration tests and remediation evidence
• Logs, alert investigations, incident exercises and staff training records

Evidence should be dated, attributable and linked to the control being tested. Screenshots without system context or reports with no indication of coverage are weak audit artefacts.

Test Technical and Operational Safeguards

Technical validation should confirm that configured controls work in practice. Assess firewalls, wireless networks, endpoint protection, encryption, secure protocols, patching, malware protection, password settings and multifactor authentication. Where segmentation is used to isolate payment systems, test whether that boundary genuinely limits access.

Run approved internal and external vulnerability scans, then arrange penetration testing at the required intervals and after significant changes. Testing should cover internet-facing services, payment applications, APIs, wireless infrastructure and segmentation controls. Findings must be prioritised according to exploitability and business impact.

Mobile commerce requires extra attention to API authentication, insecure storage, reverse engineering, certificate validation and notification behaviour. When reviewing an Android application, teams may also consult Android notification tracking guidance while checking whether sensitive payment information appears in push notifications or device logs.

Operational testing matters just as much as configuration reviews. Verify that alerts are monitored, suspicious events are investigated, backups are protected, incident procedures are rehearsed and staff know how to escalate a suspected card-data compromise.

Record Gaps and Build Remediation

Classify each finding as compliant, partially compliant or non-compliant, and record the affected requirement, evidence, risk, owner and target date. A minor documentation gap should not be treated the same way as exposed remote administration or unencrypted primary account numbers.

Remediation should address the underlying cause rather than produce a temporary workaround. If a penetration test identifies weak authentication or an exposed management interface, the action plan should specify the technical fix, validation method and accountable person. Guidance on writing a remediation plan can help structure this stage.

Prioritise work according to data exposure, exploitability, regulatory impact and operational dependency. Record compensating controls where a requirement cannot be met immediately, and obtain formal approval from the appropriate risk owner.

Common audit findings include:

• Unclear responsibility for third-party payment providers
• Incomplete inventories of cloud assets, terminals or mobile APIs
• Excessive administrator access and overdue access reviews
• Vulnerability scans that exclude important internet-facing systems
• Logs retained without effective review or alert escalation

Report Results and Sustain Compliance

The final audit report should explain scope, methodology, evidence reviewed, test results, exceptions, risk ratings and remediation status. It should distinguish between management actions and technical findings so that executives can understand exposure while security teams have practical work to complete.

Include service-provider responsibilities and shared-control assumptions. This is particularly important for Australian organisations using global cloud platforms, outsourced contact centres or overseas development teams. Contracts, attestations and responsibility matrices should show who performs each PCI DSS activity.

Compliance is an ongoing operating discipline rather than an annual paperwork exercise. Schedule recurring scans, access reviews, log monitoring, security training, incident-response testing and change assessments. A managed security service can provide continuous SIEM monitoring and threat intelligence, while periodic vulnerability assessment and penetration testing validate that controls remain effective.

A well-run audit gives Australian organisations a defensible view of payment security, clearer priorities and stronger evidence for banks, regulators and business partners. Begin with an accurate card-data inventory, validate the highest-risk controls first and maintain a remediation register until every material gap has been tested and closed.