Streamlining PCI DSS Requirement 10 With Automated Anomaly Detection
PCI DSS Requirement 10 focuses on logging and monitoring activities across systems that store, process or transmit cardholder data. The requirement is straightforward in principle: organisations need reliable records of security events, timely review of those records, and evidence that suspicious activity is investigated. In practice, many teams still rely on manual searches, spreadsheets and alerts that produce more noise than insight.
Automated anomaly detection changes the operating model. Instead of asking analysts to inspect every authentication event, administrator action and network connection, a monitoring platform can establish normal patterns, identify deviations and route meaningful exceptions to the right owner. For Australian businesses, this can make audit preparation more manageable while supporting obligations and expectations shaped by the Privacy Act, the Notifiable Data Breaches scheme and industry frameworks such as APRA CPS 234.
Why Requirement 10 Needs An Operational Rethink
Requirement 10 applies to a broad collection of systems, including servers, databases, cloud services, firewalls, identity platforms, endpoint tools and applications connected to the cardholder data environment. Logs should capture events such as user access, privileged operations, failed authentication, changes to security settings and interactions with payment data. The volume can become substantial very quickly.
A daily review does not mean someone must read every line of every log. PCI DSS expects a risk-based process supported by automated mechanisms, with review procedures that can identify anomalies and important events. A manual approach often creates two weaknesses: analysts overlook a genuine signal in a large dataset, or they record that a review occurred without showing what was examined and how exceptions were handled.
A stronger process defines which events matter, how long they are retained, what constitutes a deviation and who responds. It also links each review to the relevant system, control owner and investigation record. That structure makes Requirement 10 part of everyday security operations rather than an annual scramble before an assessment.
What A Useful Log Review Should Detect
Automated review should start with a clear inventory of log sources and their relationship to payment flows. A point-of-sale platform, payment gateway, cloud database, identity provider and remote administration tool may each generate different event formats. Centralising them in a security information and event management platform or comparable monitoring service makes cross-system analysis possible.
Useful detection rules cover both obvious and subtle behaviours. Repeated failed logins followed by a successful login, an administrator accessing a database outside normal hours, a new privileged account, disabled logging, unusual data exports and sudden changes to firewall rules deserve attention. The system should also notice activity that is technically permitted but inconsistent with a user’s normal role, location or timing.
Context improves accuracy. A login from Sydney during a normal shift may be expected, while a matching account authenticating from Sydney and Singapore within minutes could indicate credential misuse. A service account connecting to a payment database may be routine, but an interactive login by that account should generate a higher-priority exception. These distinctions reduce alert fatigue and give investigators a more useful starting point.
Turning Anomalies Into Prioritised Signals
Anomaly detection works best when it combines fixed compliance rules with behavioural baselines. Fixed rules address known requirements, such as alerting when audit logging stops or when a privileged account is created. Baselines identify unusual patterns that may not match a predefined signature, such as a sudden increase in cardholder data queries from an application that normally performs only a few lookups.
The model should not be treated as a black box. Analysts and auditors need to understand why an event was flagged, which data sources contributed to the decision and what action followed. A useful alert includes the user or service identity, timestamp, source and destination, affected asset, event type, risk level and related activity. It should also preserve the original log record so investigators can validate the finding.
| Review area | Example anomaly | Automated response | Evidence retained |
|---|---|---|---|
| Authentication | Multiple failures followed by a successful login from an unusual region | Raise a high-priority alert and require investigation | Login events, identity context and analyst disposition |
| Privileged access | New administrator account created outside an approved change window | Notify the control owner and open an exception | Account change, approval record and ticket history |
| Cardholder data access | Query volume sharply exceeds the application baseline | Correlate database and application logs for review | Query metadata, baseline comparison and case notes |
| Configuration | Logging or time synchronisation settings changed | Escalate immediately and verify the affected host | Change event, host details and remediation record |
| Log availability | A required source stops forwarding events | Alert operations and track restoration | Monitoring alert, outage duration and recovery evidence |
Risk scoring helps teams focus on events that could affect the cardholder data environment. A single failed login may be unimportant, while hundreds of failures followed by a successful privileged session may require immediate escalation. Scoring should account for asset criticality, user privilege, event sequence, geographic context and whether the activity involves payment data.
Embedding Monitoring In Engineering Workflows
Requirement 10 is easier to maintain when logging and alerting are designed into systems before they reach production. Product engineering teams can define standard audit events in application code, provision log destinations through infrastructure as code and test that critical events are generated during deployment. This prevents a common gap where infrastructure logs exist but application-level actions remain invisible.
Continuous compliance tooling can check whether required log sources are connected, whether retention settings are appropriate and whether changes introduce monitoring gaps. It can also map controls to owners and create evidence as work occurs. For teams using GitHub, GitLab, Jira or similar platforms, a change to an authentication service can trigger checks for logging coverage, access review and approval.
This approach suits Australian startups and growing SaaS companies that need to demonstrate mature controls to enterprise customers without building a large governance department. A Brisbane technology company selling into banks, for example, may encounter detailed security questionnaires before its first major contract. Demonstrating that audit events are tested in CI/CD and monitored continuously can support that sales process as well as the formal PCI assessment.
Automated governance should complement, rather than replace, human judgement. An engineer may know that a burst of database activity came from an approved migration, while an automated system sees only a deviation from normal behaviour. The workflow should allow the responsible person to document that context, link an approved change and close the alert with a traceable explanation.
Creating Evidence Auditors Can Rely On
A compliant review process needs more than alerts. Assessors may look for proof that logs are collected from in-scope systems, protected from unauthorised alteration, reviewed at the required frequency and retained for the required period. They may also examine how failed log collection, time drift and exceptions are managed.
Every detection should produce a useful evidence trail. That can include the triggering events, detection rule or baseline, assigned reviewer, investigation notes, approval, remediation and closure date. Immutable storage or controlled access to the review record helps demonstrate that evidence was not casually changed after the fact. Accurate time synchronisation across systems is equally important because event sequences are difficult to interpret when timestamps disagree.
Retention policies should reflect PCI DSS requirements and the organisation’s wider legal and contractual obligations. The current PCI DSS standard requires audit log history to be retained for at least 12 months, with at least the most recent three months immediately available for analysis. Australian organisations should align this with their internal retention schedule, contractual commitments and privacy risk, avoiding indefinite storage of personal information without a defined purpose.
Teams can reduce preparation effort by maintaining an evidence pack continuously rather than exporting material before an audit. Automated control tests, exception records and review summaries can be associated with the relevant Requirement 10 controls. For organisations arranging continuous ASV scans, connecting scan results with governance workflows provides another consistent source of assessment evidence.
Making The Model Work In Australian Operations
Australian organisations often operate across multiple time zones, outsourced service providers and cloud regions. A Melbourne support team may monitor systems hosted in Sydney, while an offshore development group makes approved changes outside local business hours. Detection rules must distinguish legitimate distributed operations from suspicious access rather than treating every late-night event as an incident.
Location signals need careful handling. An IP address can indicate a VPN exit point, a cloud service or a corporate office rather than a person’s physical location. Behavioural context, device identity, change approvals and identity-provider records should be considered together. This is especially relevant for businesses using hybrid work arrangements in Perth, Adelaide or regional areas, where fixed assumptions about office networks can create unnecessary alerts.
Regulatory context also matters. The Privacy Act and Notifiable Data Breaches scheme make security incidents and personal information handling important considerations beyond PCI DSS. Financial services organisations may need to account for APRA expectations, including CPS 234 requirements around information security capability, control testing and incident management. PCI evidence does not automatically satisfy every Australian obligation, but a well-designed logging programme can provide useful supporting evidence across several frameworks.
Finally, monitoring ownership should be explicit. Security teams can manage detection logic and incident triage, while platform engineers maintain log pipelines and application teams own event quality. Regular tuning sessions should review false positives, missed detections, new assets and changes to payment flows. With clear accountability, automated anomaly detection becomes a dependable control: it highlights meaningful deviations, preserves the reasoning behind each review and keeps the organisation ready for its next PCI DSS assessment.