Simple, Affordable, Log Management and Analysis.
14 days free trial. No credit card required.
Requirement 10 is the logging requirement, and it is the one most often failed on a first assessment. This page walks through every sub-requirement, what an assessor actually asks for, and which parts a log management platform can satisfy on your behalf, and which parts it cannot.
The Payment Card Industry (PCI) Data Security Standard (DSS) is an information security standard for organizations that handle branded credit cards from major card providers (e.g., Discover, Visa, AMEX, MasterCard). While mandated by the card providers, it's administered by the PCI Security Standards Council and aims to ensure organizations processing cardholder data maintain secure environments.
The framework is built around six goals and twelve requirements:
| Goal | DSS Requirements |
|---|---|
| Build and Maintain a Secure Network and Systems |
|
| Protect Account Data |
|
| Maintain a Vulnerability Management Program |
|
| Implement Strong Access Control Measures |
|
| Regularly Monitor and Test Networks |
|
| Maintain an Information Security Policy |
|
The PCI DSS requirement Trunc directly supports is #10 – Log and Monitor All Access to System Components and Cardholder Data. Logging is critical not just for compliance but for visibility, alerting, and forensic investigations.
Requirement 10 has seven parts. Most guides cover three of them. Below is all seven, what each one is actually asking, and which of them a log management platform can satisfy for you.
No product makes an organisation PCI compliant. A platform can hold the evidence, protect it, and prove it exists. The scope decisions, the procedures and the sign-off remain yours. Anything on this page marked Yours is work no vendor can do for you, and we would rather say so here than have an assessor say it to you later.
| Requirement | What it asks for | Where Trunc fits |
|---|---|---|
| 10.1 Processes and mechanisms are defined and documented | A written policy covering what is logged, who reviews it, how long it is kept, and who may read it. Roles assigned and understood. | Yours. Trunc generates a draft policy from your live configuration, using the real source list, retention setting and alert destinations. You adapt it and sign it. |
| 10.2.1 Audit logs enabled on all system components | Every in-scope system is producing logs, and those logs are reaching somewhere they can be reviewed. | Shared. You decide what is in scope and point it at us; we show you exactly which systems are reporting so the gap between the two is visible. |
| 10.2.1.1 – 10.2.1.7 The specific events that must be captured | Individual user access to cardholder data, all administrative actions, access to the audit logs themselves, invalid access attempts, credential changes, starting or stopping of logging, and creation or deletion of system-level objects. | Trunc. Each of these has a category applied at parse time, covering authentication success and failure, privilege escalation, account lifecycle and audit log tampering. The evidence for each sub-requirement is one search away rather than a manual hunt. |
| 10.2.2 Each record carries the required fields | User ID, event type, date and time, success or failure, origination, and the identity of the affected system or data. | Trunc. Every event is parsed into these fields on arrival and each is individually searchable, rather than being left as a line of text you have to grep. |
| 10.3.1 Read access limited to those with a job-related need | Only named people can read the logs, each with their own login, and access is revoked when a role changes. | Shared. Individual logins with four access levels are built in. Deciding who gets which is yours. |
| 10.3.2 Logs protected from unauthorised modification | Whoever produced a log cannot go back and alter it. | Trunc. Records are append-only once received. The sending system holds a write-only credential and has no way to read, modify or delete anything that has already arrived. |
| 10.3.3 Backed up promptly to a secure, central location | Logs leave the originating host quickly, so a compromised machine cannot destroy the evidence of its own compromise. | Trunc. This is what the product is. Logs are shipped as they are written, encrypted in transit, to infrastructure your systems have no access to. |
| 10.3.4 File integrity monitoring on the audit logs | Changes to log files are detected. | Trunc. Worth understanding what this requirement assumes: it exists because logs traditionally sit on the machine that wrote them, where they can be edited. Once a record is here it cannot be altered at all, so there is nothing to detect. FIM on the origin host still covers the seconds before shipping, and we ingest those events too. |
| 10.4.1 Security logs reviewed at least once daily | Security events, and logs from every system that stores, processes or transmits cardholder data, looked at daily. | Shared. The security review runs continuously and alerts reach a person in real time. Somebody still has to look and act. That part is a procedure, not a product. |
| 10.4.1.1 Automated mechanisms perform the review | Added in v4.0. The standard now expects automation rather than a person reading files, because manual review does not scale. | Trunc. Every event is categorised and severity-rated on arrival and matched against detection rules for brute force, privilege escalation, scanning and repeated failures. That is the automated mechanism this sub-requirement is asking for. |
| 10.4.2 – 10.4.3 Everything else reviewed periodically, and exceptions addressed | Non-critical systems reviewed on a frequency you justify through a risk analysis, and anything found gets acted on. | Shared. We surface the anomalies; the risk analysis and the follow-through are yours. |
| 10.5.1 Twelve months retained, three immediately available | A year of history exists, and the most recent three months can be searched without restoring anything from cold storage. | Trunc. Retention is a setting. Everything inside the window stays indexed and searchable. There is no restore step, because nothing is archived out of reach. |
| 10.6.1 – 10.6.3 Time synchronisation | All systems agree on the time, from a controlled source, and the time settings themselves are protected. | Yours. This happens on your systems, not ours. It matters more than it sounds: correlating an incident across three hosts is impossible if their clocks disagree. |
| 10.7.2 – 10.7.3 Failures of security controls are detected and responded to | Mandatory for all entities since 31 March 2025. Failure of any critical security control, including the audit logging mechanism itself, must be detected, alerted on, and addressed promptly. | Trunc. A system that stops sending logs is a failure of the logging mechanism, and it is the failure nobody notices, because nothing happens. We detect silence per source and alert on it. See below. |
Requirement 10.7 became mandatory for every entity in March 2025, and it asks for something logging products have historically been bad at: detecting when the logging itself has stopped.
A server that stops sending logs produces no error, no alert and no entry anywhere. It simply goes quiet. Everything looks calm, and the one system you can no longer see is the one an assessor will ask about or worse, the one an attacker is on. Most organisations discover a dead agent weeks later, when they go looking for an event that was never recorded.
Trunc tracks the reporting pattern of every source and raises it as a finding when one stops. Not a missing chart or an empty page, but a named system, how long it has been silent, and how much it was sending before it went quiet. That is 10.7.2 satisfied for the audit logging control, and it is genuinely useful the other three hundred and sixty days of the year.
Every Trunc account includes a compliance view that reports where each Requirement 10 control stands, based on the logs actually arriving. It is built for the person who has to sit across from an assessor.
What it shows
Assessors ask you to demonstrate that a control is working, not that it caught something. "We monitor for failed privilege escalation and recorded none this quarter" is a complete answer, provided you can show you were watching.
Most dashboards report that as an empty result, which reads like a gap. Ours reports it as monitored and clean, with the collection evidence beside it, because that is what it is.
Trunc simplifies PCI compliance by providing a centralized platform for collecting, storing, and analyzing logs across your infrastructure. With built-in safeguards to ensure log integrity and access control, Trunc acts as your system of record, ensuring logs remain secure, unaltered, and accessible when needed.
Whether you're preparing for an audit or investigating an incident, Trunc ensures your logging process is compliant, resilient, and efficient.
Key PCI-Aligned Features:
Written against PCI DSS v4.0. The Council publishes the standard in full. Always confirm the current wording against the document itself and with your assessor, since sub-requirement numbering has changed between versions.
14 days free trial. No credit card required.
Get
Started