PostgreSQL audit logging for PCI DSS requirement 10

Which PCI DSS requirement 10 controls PostgreSQL audit logging covers

PostgreSQL audit logging through pgAudit and the standard logging facility can supply much of the event capture that PCI DSS Requirements 10.2.1.1 to 10.2.1.7 call for, but it cannot satisfy Requirement 10 on its own. Protection of log files, limits on who may read them, central backup, change detection and retention stay with the organization and its platform, as do decisions about which databases are in scope. The standard in use is PCI DSS v4.0.1, the only active version, because v4.0 was retired on 31 December 2024. PCI DSS does not certify organizations or enforce its own requirements, so the assessor's judgment of the environment and the payment brands' rules still determine scope and the evidence an assessor will accept.

Start by mapping each required event type to a logging source before you change any settings. pgAudit can record session and object activity, such as statements that read or change tables holding primary account numbers, and the standard PostgreSQL log can record failed connection attempts and authentication failures. Role and configuration changes need checking case by case, because some are captured by pgAudit's classes and others only by server-side logging parameters. Confirm each event against your own configuration in a test environment, and record which file or setting produces it, since the assessor will ask for that mapping.

Decide early whether database logging is needed at all. PCI SSC FAQ 1081 says operating system, database and application logging may be combined as appropriate, and that database logging may be unnecessary if other logs already capture all individual access to cardholder data. Ask your assessor to confirm in writing which component records each event type, whether a central log platform already covers individual access, and whether any control will use the customized approach, which meets an objective in a different way and requires its own documentation and testing. Those answers determine how much verbose database logging you must build and operate.

Your validation path decides how the evidence is packaged. A Report on Compliance is completed by a Qualified Security Assessor, while a Self-Assessment Questionnaire is completed by the entity, and each ends with an Attestation of Compliance. Certificates are not accepted as validation. DeployOpen can plan the logging configuration, set up pgAudit and prepare evidence for the assessor, but it does not issue reports, attestations or certifications. The payment brands decide which entities must validate and run any enforcement programs.

Mapping requirements 10.2.1.1 to 10.5.1 to PostgreSQL configuration

This table maps each PCI DSS requirement 10 control in scope for a PostgreSQL database to the pgAudit or PostgreSQL setting that usually covers it. Use each row as a starting point, and treat rows marked for confirmation as design checks to complete for your chosen PostgreSQL and pgAudit versions before the build. The main takeaway is that database logging covers several controls directly, while log protection and retention depend on the logging platform around the database.

Requirement	Platform capability	Configuration
10.2.1.1: Individual user access to cardholder data	pgAudit records reads and writes per session and statement. Confirm the object scope it audits for your release.	Enable the read and write classes in pgaudit.log, and log the session user for each statement.
10.2.1.2: Administrator actions	pgAudit role and DDL classes capture privilege changes and administrative statements. Confirm coverage for the admin tasks you perform.	Enable the role and ddl classes in pgaudit.log, and keep superuser access tied to named accounts.
10.2.1.3: Access to audit logs	Log file access depends on operating system permissions and database roles, outside pgAudit. Confirm the OS audit tooling you will use.	Set the log directory owner to the PostgreSQL service account, limit group read access, and audit reads with OS tooling.
10.2.1.4: Invalid access attempts	The server writes failed login messages to its log. Confirm the message text and log level for your PostgreSQL version.	Turn on log_connections and log_disconnections, and confirm authentication failures reach the log collector.
10.2.1.5 and 10.2.1.6: Credential changes, log initialization and stopping	pgAudit role class covers password and role changes. Confirm that password changes appear in entries for your pgAudit version. Server start and stop are logged by the server.	Keep the role class in pgaudit.log, keep logging_collector on, and forward startup and shutdown messages to the central log.
10.2.1.7: System-level object creation and deletion	pgAudit DDL class records CREATE and DROP statements. Confirm coverage for the object types your schema uses.	Enable the ddl class in pgaudit.log. Add catalog logging only if you need catalog queries recorded.
10.2.2: Audit log entry fields	log_line_prefix sets timestamp, user, database, client and session fields. Confirm which outcome fields appear for each event type.	Set log_line_prefix to include timestamp, user, database, client address, process ID and session ID.
10.3: Log read access, protection, backup and change detection	Read limits, immutability, central backup and change detection come from the host and log platform. Confirm each control for your build.	Ship logs to a central server with restricted read roles, immutable storage where available, and file integrity monitoring.
10.5.1: Retention of audit history	PostgreSQL does not enforce a 12-month retention period by itself. Confirm rotation and archive tooling for your environment.	Set rotation and archiving to keep at least 12 months of history, with the most recent three months searchable online.

How pgAudit captures individual access to cardholder data

pgAudit writes detailed audit records through PostgreSQL's standard logging facility, so its output lands in the same log stream your team already collects and protects. For requirement 10.2.1.1, the core question is whether each person who reads or changes cardholder data leaves a record tied to their own database identity. pgAudit offers two modes. Session logging records statements by session, which captures broad activity such as every query a role runs. Object logging records only statements that touch specific tables, columns or functions you name. Session logging is wide and produces more volume, while object logging is narrow and precise but only sees what you configured. Most cardholder environments need a deliberate mix of the two.

Settings should follow an inventory of the database. Before you enable anything, list every table, view, sequence and function that holds or exposes primary account numbers or sensitive authentication data. Then list every database role that touches them, including application service accounts, reporting users, backup jobs and DBA accounts. Each role should map to a named person or a documented process, because 10.2.1.1 depends on tying access to an individual. Record which roles read cardholder data, which only write it, and which should never reach it. That inventory determines what the object audit role covers, which session-level classes you enable, and how much log volume to expect. Confirm the list with the data owners and with the team that defines the cardholder data environment boundary before any configuration is written.

Requirement 10.2.1.2 covers actions taken by anyone with administrative access. In PostgreSQL that usually means superusers, roles with CREATEROLE or CREATEDB, owners of cardholder schemas and the accounts used for maintenance. Session-level records are generally what capture DDL, role changes and configuration activity, since those statements may not reference a particular table. Decide whether superuser sessions are logged at the same depth as application roles, and whether break-glass accounts need separate handling. pgAudit only records what passes through PostgreSQL, so confirm that operating system and shell activity on the database host is captured by other controls. Also confirm that the people who review administrator activity can actually reach the log destination, because records that nobody reviews do not help during an assessment.

Before you choose a pgAudit release, confirm that it supports the PostgreSQL major version you run today and the one you plan to move to. Extension releases follow their own compatibility matrix, so a version that loads on one PostgreSQL major release may not build or load on another. Check this against the pgAudit repository and against your installation method, including packages from your Linux distribution or a container image you build yourself. Pin the extension version in your change records and retest the audit output after every PostgreSQL major upgrade, because a silent change in what gets logged is the kind of gap an assessor will ask about. Also confirm that your PostgreSQL release is still within its support window.

Which fields each audit entry needs under requirement 10.2.2

Requirement 10.2.2 sets the minimum content of each audit log entry. The five fields below form a checklist your PostgreSQL logging configuration must satisfy before pgAudit or server logs can serve as audit evidence. Two of them, success or failure and origination, are often missing from default settings, so verify both against your own output.

Event type

Each entry must state what happened, such as a SELECT, an INSERT, a DDL statement, a role change or a configuration change. With pgAudit, each AUDIT line carries a class (for example READ, WRITE, DDL, ROLE or MISC) and a command tag, and together these identify the event type. Set pgaudit.log to the classes your cardholder data environment needs, then confirm each class appears in a test run. Standard statement logging can record the statement text but does not classify it by itself.

Date and time

Every line needs a timestamp precise enough to order events across hosts. Include %m (milliseconds) or %t in log_line_prefix, and set log_timezone to a fixed zone such as UTC so entries from the primary, standbys and any pooler sort correctly. Confirm that clocks on every database and logging host are synchronized to a trusted time source before you rely on event sequences during an investigation. Check that your log shipper keeps the timestamp format intact.

Success or failure

A reviewer must be able to tell whether an attempted action succeeded. Standard server logging records failures as ERROR or FATAL lines, but pgAudit output alone may not show whether a logged statement completed, so a successful and a failed attempt can look alike. Confirm this for your PostgreSQL and pgAudit versions rather than assuming coverage. Test it by running one permitted query and one query against a table the test role cannot read, then check that each outcome is visible and correlatable in the log.

Origination

Each entry must show where the activity came from: the client address, the database user, the application name and the process ID. Include %u, %d, %r or %h, %a and %p in log_line_prefix. Connections through a pooler such as PgBouncer may show the pooler's address instead of the originating host, so confirm how the pooler passes client details and whether applications set application_name. Test by connecting from a known host and checking that the address and user match what you expect.

Identity of affected data

Each entry must name the object the activity touched, such as the database, schema, table, column or function. pgAudit's object logging, controlled through pgaudit.role, records access to objects the audit role is granted, and the AUDIT line includes the statement text that names them. Confirm that every cardholder table is covered, that schema-qualified names appear in output, and that statements using views or functions produce identifiable object names in your test.

When database logging can be skipped under PCI SSC FAQ 1081

PCI SSC FAQ 1081 says operating system, database and application logging may be combined, and that database logging may be unnecessary if other logs already capture all individual access to cardholder data. For a PostgreSQL database, that means you can skip pgAudit or native PostgreSQL logging of cardholder table access only if another log source records every individual access to that data, with the identity of the person or process and what was accessed. This is a scope decision your organization makes, documents and presents to the assessor. The assessor decides whether the decision holds. DeployOpen can help you build the test and assemble the evidence, but we cannot certify that a skip is acceptable, and no audit report or attestation from us should be read as approving it.

Start with an inventory of every path that can reach the cardholder tables. Include application service accounts, DBA sessions opened with psql or a administration tool, reporting and BI connections, batch and ETL jobs, support or break-glass access, and any replication or backup process that reads the data. For each path, record the account used, where the connection originates and which log source would show it. Then test each path with known activity. Run a controlled query as a named individual through every route and confirm the other log source shows that individual, the object touched and the outcome. If a path shows only a shared service account, that path is not covered and the database must keep its own record for it.

Direct database connections are the case most often missed. Application logs show what the application did, not what a person typed into a database client, so a DBA or support engineer querying cardholder data directly may leave no trace in application logs. Operating system or network logs can show that a connection was made, but usually not which statements ran against which rows. Test this path explicitly: connect directly from an administrator workstation, run a read against a cardholder table, and check each candidate log for the user, the statement or object and the time. Also test whether a connection can be made without going through the application at all, since a route that exists but is unmonitored undermines the whole argument. Confirm this against your pg_hba.conf rules and network controls as they actually run.

Keep the evidence as a dated package that an assessor can follow without help. It should include the access path inventory, the test plan, the test commands and their output, sample log entries showing the fields required by Requirement 10.2.2, configuration exports for each log source, and a written conclusion signed by the accountable owner. Record who ran the tests, which PCI DSS version the assessment uses (v4.0.1 is the active version), and any gaps with the compensating or remediation action taken. Repeat the test when the architecture changes, such as a new reporting tool, a new replica or a changed authentication method. Ask your Qualified Security Assessor to review the approach before the test, not after, so that a skip is not discovered late in the assessment.

Evidence auditors ask for and how to keep it for 12 months

Assessors ask for a small set of artifacts that show logging is configured, what it records, how long it is kept and who can read it. Keep each item current with the database version and every change, and store it where the audit team can retrieve it without asking the platform team.

Configuration files as evidence

Keep the postgresql.conf and pg_hba.conf settings that enable logging, along with the pgAudit parameters that choose which statement classes and objects are recorded. Store them under version control so every change has an author, date and reason. Assessors compare these files against the events your logging claims to capture, so confirm that the files you provide match the settings running on each primary and standby.

Sample entries for each 10.2.1 event

Provide one sample log entry for each event type covered by Requirements 10.2.1.1 to 10.2.1.7, generated from a test environment that mirrors production logging. Each sample should show the fields required by Requirement 10.2.2, including event type, date and time, success or failure, origin and the affected resource. Redact any cardholder data before the samples leave your environment.

Audit history for 12 months

Requirement 10.5.1 requires audit log history to be kept for at least 12 months, with at least the most recent three months immediately available for analysis. Retention is therefore two tiers: recent logs searchable in your log platform and older logs archived in a form you can restore. Document both tiers and confirm that deletion jobs enforce the period you state.

Backup records for log archives

Keep records of the jobs that copy logs and WAL archives to a secure central location, including schedules, destinations, success reports and restore tests. Requirement 10.3 expects logs to be backed up promptly to a secure central server, so the records should show that copies arrive on time and can be read. Include the integrity checks that confirm archived files have not changed.

Access lists for log readers

Maintain a current list of every person and service account that can read audit logs, the archive and the audit tables themselves. Requirement 10.3 limits read access to what each role needs for its job, so record the justification and approver for each grant and the date of each removal. Review the list on a set schedule and keep the review results as evidence.

Assessment record and attestation

The assessment record is the Report on Compliance completed by a Qualified Security Assessor, or the Self-Assessment Questionnaire, each with its Attestation of Compliance. The PCI SSC does not accept certificates as validation of compliance, so do not offer one in place of these documents. Ask your acquirer or payment brand which template applies to your environment before you collect evidence.

Configuring PostgreSQL audit logging for requirement 10 in order

This sequence takes a self-hosted PostgreSQL cluster from scope definition to logs that cover the PCI DSS 10.2.1 events, carry the 10.2.2 fields, are protected under 10.3, and are kept for the required period. Each step ends with a check the team can record as evidence for the assessor.

Confirm scope and identify cardholder data stores
The security lead and database owner list every PostgreSQL cluster, database and replica that stores, processes or transmits cardholder data, or that could affect the security of that environment. Include backups, reporting copies and administrative hosts. Confirm with the assessor or QSA whether database logging is needed or whether other logs already capture all individual access to cardholder data, as PCI SSC FAQ 1081 describes. Done when the list is signed off and each in-scope instance has an owner and a log destination.
Confirm PostgreSQL and pgAudit version compatibility
The DBA checks that the PostgreSQL major version in use is still supported under the PostgreSQL versioning policy, and that the pgAudit release matches that major version. Confirm the exact pgAudit release and its build against the running server with the pgAudit repository and your packaging source. Record the versions, the planned upgrade path and any gaps. Done when the version matrix is documented and a test instance loads the extension without errors.
Set logging and pgAudit parameters for 10.2.1 events
The DBA enables the pgAudit extension and configures its classes and session or object logging so the database records individual user access to cardholder data, administrator actions, changes to authentication credentials, invalid access attempts, and creation and deletion of system-level objects. Connection and disconnection logging is set in the core server settings. Confirm the parameter names for your version in its documentation. Done when a test role's reads of a cardholder table, a password change and a failed login each produce an entry.
Set the log format for 10.2.2 fields
The DBA sets log_line_prefix and the log output format so that each entry includes the date and time, the user, the database, the client origin and the process identifier. Event type comes from pgAudit's classification and success or failure from the error and statement fields, so confirm which of these your chosen format exposes. Where a required field is absent, the team decides whether to add it through the prefix or a log parser. Done when a sample entry is reviewed line by line against each 10.2.2 element.
Restrict log access and enable change detection
The systems administrator sets the log directory and files so that only the PostgreSQL service account can write to them, and grants read access only to named roles tied to a job need, as PCI DSS 10.3 requires. Confirm that database administrators cannot silently edit or truncate logs they are auditing. Then enable file integrity monitoring or change detection on the log directory with the team's chosen tool, and alert on modification or deletion. Done when an unauthorized read attempt is refused and a test edit triggers an alert.
Ship logs to a central secure server
The platform engineer configures a log shipper, such as the collector your organization already runs, to forward PostgreSQL logs promptly to a central server that is separate from the database hosts. Transport should be encrypted and authenticated, and the central store should be writable only by the shipping identity. Confirm delivery latency with your assessor's expectations for promptness and check that a log file rotation does not drop lines. Done when entries from the database appear on the central server within the interval the team has agreed and the copy matches the source.
Set retention for 12 months with 3 months online
The operations lead sets retention so that audit log history is kept for at least 12 months, as PCI DSS 10.5.1 requires, and confirms that at least the most recent three months are immediately available for analysis. Older logs can move to archival storage if they remain retrievable and protected. Confirm the storage sizing with the central logging platform owner, because volume depends on how many events the enabled pgAudit classes produce. Done when a restore test retrieves an archived month and the online window is queryable.
Test each logged event with sample activity
The QA or security engineer runs scripted activity under a test account for every event in scope: reads and writes to a cardholder table, privileged actions, credential changes, failed logins, log configuration changes, and object creation and deletion. Each run is matched to its central log entry and checked against the 10.2.1 and 10.2.2 requirements. Record the test date, the scripts, the expected and actual lines, and any gaps. Done when every event has a passing record that the assessor can review, and failed tests have a tracked fix.

What PostgreSQL and pgAudit do not cover for requirement 10

pgAudit and PostgreSQL logging produce the audit records, but they do not protect, move, review or prove them. The cards below cover the controls around the database that requirement 10 expects you to build, along with the design choices that can quietly break log continuity or change which events are captured.

Central log backup and secure log server

PostgreSQL writes audit entries to its own logging destination, and nothing in the database forwards them to a central, access-restricted server. Requirement 10.3 expects logs to be promptly backed up to a secure central server, so you need a shipping pipeline, a separate destination that database administrators cannot quietly edit, and a test that shows entries arriving. Confirm the transport, its failure behavior and who can administer the receiving system.

File integrity monitoring on audit logs

Requirement 10.3 expects log files to be protected from modification and monitored for changes. PostgreSQL does not check its own log files for tampering. Plan a file integrity monitoring or change detection tool on the log directory and the central store, define which changes raise alerts, and document who reviews them. Confirm that the tool covers rotated and compressed files as well as active ones.

Read access to logs limited by job need

Anyone who can read the database log files or the central log store can see executed statements, which may contain cardholder data or sensitive parameters. Requirement 10.3 expects read access to be restricted by job need. Map each role that needs logs, such as security operations or platform support, to a defined access level, and remove shared operating system accounts from the log directory. Confirm that pgAudit output does not leak data values you have chosen to exclude.

Organizational processes for reviewing logs

Requirement 10 is also about people. Someone must own the review schedule, the criteria for escalation, the handling of suspicious events and the records that show reviews happened. None of this is provided by PostgreSQL or pgAudit. Ask your team to define the review cadence, the owner for each log source and how exceptions are recorded, then verify that the process produces evidence an assessor can inspect.

Scope decision on database logging

PCI SSC FAQ 1081 says database logging may be unnecessary when other logs already capture all individual access to cardholder data. Whether to rely on that position is a scope decision you must document with evidence, covering which logs capture each access path and where the gaps are. Confirm the decision with your qualified assessor before you turn off database-level audit events.

Log continuity during failover and pooled connections

PostgreSQL does not provide software that detects a primary failure and notifies a standby, so audit log continuity during failover depends on the external tools you choose. Connection poolers such as PgBouncer can also change which client address appears in entries, so the source address field must be tested after pooling is added. Test both paths before relying on the logs as evidence, and record the results.

Evidence for a customized approach

PCI DSS v4.x allows a customized approach that meets a stated objective in a different way, but it needs its own documented design, testing and evidence. Any replacement for a defined logging control, such as a different log shipper or alternative integrity checks, must show how the objective is still met. Plan the evidence set early and confirm the approach with your assessor before you build it.

Choosing a supported PostgreSQL version for the audit trail

An audit configuration is only as durable as the database version under it. If the server falls out of support, the logging that PCI DSS requirement 10 depends on runs on a platform that no longer receives fixes, and the pgAudit settings you tuned become a maintenance liability. According to the PostgreSQL versioning policy, PostgreSQL 14 is supported until November 12, 2026. PostgreSQL 15 is supported until November 11, 2027, 16 until November 9, 2028, 17 until November 8, 2029, and 18 until November 14, 2030. Versions 13 and earlier are unsupported. For a new audit trail, choose a major version whose end date covers the period in which the cardholder data environment will run on it.

Minor releases are a different kind of change. PostgreSQL issues minor releases at least once every three months, and they never change the internal storage format. Applying one means replacing executables and restarting the server, so existing audit settings and the data already written to the log are not expected to change. Treat minor updates as routine patching, and keep a dated record of the minor version running in each environment for your evidence file. Confirm with the pgAudit project which extension builds support the minor version you move to, because the extension's release notes define that compatibility.

Major upgrades are where audit settings need retesting. Before any major change, run the audit configuration against a copy of the cluster and confirm three things: that pgAudit loads and records the session and object events you specified, that log lines still carry the fields your review and monitoring process parses, and that log files keep their permissions and rotation behavior. Test each target major version separately. PostgreSQL documents dump and restore with pg_dumpall, pg_upgrade and logical replication as upgrade routes, and the route you choose determines which checks matter most. Ask your database team which route they intend to use before the test plan is written.

Planned major upgrades are a separate piece of work and should have their own scope, change window and approval. The upgrade involves the method chosen, rollback, backup verification and application testing, and it should finish before the end date of the version you run today. With PostgreSQL 14 approaching its end date, start that planning early. The PostgreSQL 18 release announcement states that pg_upgrade retains planner statistics across major upgrades, but confirm that behavior in your own test before you rely on it. Keep the audit retesting described above as an exit criterion of the upgrade project, so the logging is verified on the new version before cutover is accepted.

How much PCI DSS requirement 10 logging work can our team do alone?

What drives the cost and effort of PCI DSS requirement 10 logging work?

The main drivers are the number of PostgreSQL clusters that store or can reach cardholder data, how far the cardholder data environment extends, and which PostgreSQL major versions you run. Effort also rises with the number of log sources that must be combined, the design of log shipping to a central server, and the volume of evidence an assessor will sample.

Cost components: internal staff time for scope and access work, the configuration and testing of pgAudit and PostgreSQL logging, and the work to protect and retain logs for at least 12 months. Most of this is one-time. Retention storage, log review and periodic validation recur.

Ask which of these drivers applies to your environment before comparing options.

How long does a PostgreSQL audit logging project take?

The duration depends on the written scope, so no single timeline applies to every environment. The variables that move it most are the number of databases in scope, whether pgAudit is already installed and tested, how many environments need separate configuration, and whether a central log server and file integrity monitoring already exist.

Approval cycles also affect duration. Your change process, your assessor's review schedule and any required test windows can add time that the technical work does not.

Ask for milestones tied to deliverables and for the client decisions each milestone depends on.

What does the organization need to provide for an outside logging engagement?

The engagement needs a clear scope, access and a named owner for each log source. Your team should provide the list of PostgreSQL clusters, their versions, the systems that connect to them and the data flows that carry cardholder data.

The main inputs are:

Scope: the cardholder data environment boundary and the databases inside it.
Access: administrative access to test and production clusters, log hosts and backup systems, granted under your change controls.
Log owners: people who approve log retention, read access and alert handling.
Assessor contact: the Qualified Security Assessor or internal assessor who will review the evidence.

Delays usually come from missing owners or unclear scope, not from the configuration work.

Can an internal team implement PCI DSS logging for PostgreSQL without a partner?

An internal team can do this work if it has strong PostgreSQL administration skills and a clear reading of the requirements. The team must cover the events in Requirements 10.2.1.1 to 10.2.1.7, the fields each entry needs under 10.2.2, read-access limits and log protection under 10.3, and 12-month retention under 10.5.1.

The usual gaps are pgAudit settings that differ by PostgreSQL version, log integrity monitoring, central backup of logs, and evidence that shows the controls work over time. PCI SSC FAQ 1081 allows operating system, database and application logs to be combined, and says database logging may be unnecessary where other logs already capture all individual access to cardholder data. Confirm that position with your assessor before you skip any database logging.

Does DeployOpen certify PCI DSS compliance for our PostgreSQL environment?

No. DeployOpen does not certify compliance, issue audit reports or issue attestations. It can plan, implement, harden and document PostgreSQL logging, and prepare the systems, controls and evidence that an assessment will review.

PCI DSS validation is documented on official PCI SSC templates. An entity either completes a Report on Compliance with a Qualified Security Assessor or completes a Self-Assessment Questionnaire, and in both cases signs an Attestation of Compliance. PCI SSC states that certificates are not recognized as validation. The payment brands decide which entities must validate and run any enforcement.

Ask your acquirer or assessor which validation path applies to your organization.

What should a written quote for PCI DSS logging work include?

A quote follows from the written scope, so ask for the scope before any figure. The scope statement should list the PostgreSQL clusters, their major versions, the environments, the log destinations and the cardholder data boundary.

A useful quote separates:

Deliverables: configuration, documentation, test results and evidence packages.
Assumptions: the inputs and access the work depends on.
Exclusions: items such as assessor fees, SIEM licenses or storage hardware.
Client responsibilities: owners, approvals and change windows.
Recurring items: retention support, log review or retainers, listed apart from one-time work.

Also ask how changes to scope are handled and what acceptance criteria close each deliverable.

How DeployOpen scopes and delivers requirement 10 logging evidence

DeployOpen treats PCI DSS requirement 10 for PostgreSQL as a scoped deliverable: we first decide which logs the cardholder data environment needs, then configure pgAudit and PostgreSQL logging to capture those events, and document the evidence an assessor will ask for. The work runs inside infrastructure you control, and your QSA or internal assessor makes the compliance determination.

How we scope

Map which PostgreSQL clusters store, process or could affect cardholder data, and record that boundary in writing
Confirm with your assessor whether database logging is needed or whether other logs already capture individual access
Agree the event list against requirements 10.2.1.1 to 10.2.1.7 and the fields each entry must carry under 10.2.2
Engagements are fixed-scope: deliverables, environments and timelines are agreed in writing before work starts

How we build

Configure pgAudit and PostgreSQL log settings per cluster, with session and object classes chosen from the scoped event list
Set log destinations, file permissions and ownership so log files resist modification and read access follows job need
Forward logs to a central, protected store and verify that entries include event type, time, outcome, origin and affected resource
Test with controlled admin, access and failed-login actions, and record the results alongside the configuration

How we hand over

Deliver a configuration baseline, a logging runbook and a field-by-field mapping to requirement 10.2.2 for your assessor
Document the 12-month retention design under 10.5.1, including the three months immediately available for analysis
Provide integrity monitoring or change detection setup for audit log files, as agreed in the scope
Walk your operations and security staff through alert handling, log review and restore of archived logs

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Re-check logging configuration after PostgreSQL minor and major upgrades, since settings and extension versions can change
Review the scope when PCI DSS versions change; v4.0.1 is the only active version and the next iteration has no release date yet
Your QSA or internal assessor issues the Report on Compliance or Self-Assessment Questionnaire; DeployOpen supplies the evidence