PR.PS-04 log generation: what the requirement asks for
If you must show that logs exist, are complete and reach monitoring, PR.PS-04 is the NIST CSF 2.0 Subcategory you will be asked about. It sits in the Platform Security (PR.PS) Category of the PROTECT Function. Its outcome is that log records are generated and made available for continuous monitoring. NIST CSF 2.0 has no certification, and NIST states it has no plans for a conformity assessment program, so nobody issues a PR.PS-04 certificate. Your evidence is judged by an internal review or an independent assessment against your own Target Profile, and the question is whether your logs can support detection and investigation in practice.
The risk behind this Subcategory is a blind spot. If an operating system does not record authentication events, an application writes logs only to a local file, or a cloud service's audit trail is never switched on, the activity that matters most can happen with no record. Detection teams then cannot correlate events, and incident responders cannot reconstruct what happened. The difficulty is consistency. Each operating system, application and cloud service has its own logging settings, default retention and output format, and many logs are never forwarded to the central logging infrastructure at all. A host that logs locally but never ships those records is invisible to the monitoring team.
Start with an inventory of log sources drawn from your asset records, then confirm for each one which events are generated, where they are stored and whether they arrive at your logging platform. Ask your engineers to show a test event travelling end to end, and ask who owns each source's logging configuration. NIST publishes three Implementation Examples for this Subcategory, covering configuring systems and cloud services to generate logs, sending them securely, and recording the data that zero trust architectures need. Confirm with your assessor or implementation partner which of these your own profile uses. Clock accuracy also matters, because timestamps from unsynchronized systems make correlation unreliable.
Which systems, logs and teams fall under PR.PS-04
PR.PS-04 applies wherever an organization produces security-relevant records, so scope starts with the asset inventory rather than with a logging product. The cards below are the scoping decisions that change the work most, and each one names the team that usually owns it.
Operating system audit records
Host operating systems are usually the first sources to configure, covering authentication events, privilege use, service starts and changes to security settings. Platform engineering or systems administration typically owns the configuration, and the security team should confirm which events are forwarded. Check that every server image in the build pipeline carries the same logging settings, so new hosts do not appear in the inventory without records. Confirm event coverage per operating system version, not per product name.
Business application logs
Line-of-business applications often record user actions, data access and administrative changes in their own formats, and these records may never reach the operating system log. Application owners or product teams usually control these settings, so the logging requirement needs to be written into their backlog. Check whether each application can send records to a central destination or only writes local files that rotate out.
Identity system events
Directory services, single sign-on and privileged access tools record logins, failed attempts, token issuance and group membership changes, which are central to investigating account misuse. The identity team typically owns these sources, and it should agree with the security operations team on which events are retained and for how long. Check that identity logs cover administrative sessions as well as end-user sign-ins.
Network device records
Firewalls, routers, switches and load balancers generate records about allowed and denied traffic, configuration changes and administrative logins. The network team usually owns these devices, but the security team needs to define the minimum set of records it must receive. Check that device clocks are synchronized with the same time source as the rest of the estate, because mismatched timestamps make cross-device correlation unreliable.
Cloud control plane activity
Cloud provider management APIs record who created, changed or deleted resources, and these records often matter more than workload logs during an incident. Cloud platform or account owners usually enable and route these trails, so confirm which accounts, regions and subscriptions are covered. Check that the trail covers every account in the inventory, including those created by teams outside central IT.
SaaS audit trails and zero trust data
Software-as-a-service products expose audit logs with their own retention limits, and the vendor usually decides what is recorded. Zero trust architectures also need specific recorded data, such as device posture, access decisions and per-request identity context, as the NIST Implementation Examples for PR.PS-04 describe. Business owners of each SaaS product and the architecture team should jointly confirm which events can be exported, how often, and whether they meet the zero trust data needs.
How an assessor tests PR.PS-04
This table sets out, for each element of the PR.PS-04 outcome, how an assessor samples and tests it, what evidence is requested and where findings usually arise. Read it as a checklist of what to have ready before an independent review, and note that the assessor is separate from the team that implemented the logging.
| Element | Test approach | Evidence requested | Common findings |
|---|---|---|---|
| Log generation per source type | Select a sample of operating systems, applications and cloud services in scope, then check that audit logging is enabled for each and that the event types needed for security monitoring are captured. | Logging configuration files, cloud audit settings and a sample of log entries showing expected event types from each sampled source. | Sources missing from the inventory, audit logging left at defaults, or cloud services where logging was never switched on. |
| Secure transmission to logging infrastructure | Trace a sample of logs from source to collector and check the transport settings, encryption, authentication of senders and the handling of any local buffering. | Forwarder and collector configuration, certificate or TLS settings, and network paths showing the route used. | Logs sent in clear text, collectors accepting unauthenticated senders, or forwarders that silently drop records when the link fails. |
| Availability for continuous monitoring | Confirm that the monitoring team can query the logs, that retention covers the periods the organization sets, and that alerts depend on the same data. | Access lists for the logging platform, retention settings, and evidence that monitoring rules run against the stored records. | Monitoring teams with no query access, retention shorter than the organization's own stated period, or alert rules that read from a different source than the one reviewed. |
| Time accuracy | Check that the systems that produce logs synchronize their clocks to an approved time source and that the offsets are recorded and monitored. | Time synchronization configuration, the time sources named, and monitoring output showing offsets over a sampled period. | Hosts with unsynchronized clocks, mixed time zones across sources, or no record of which time source each system uses. |
| Independence of the review | The assessor reviews the controls without taking part in building them. Ask the assessor to state its independence and to record which evidence came from the implementing team. | Assessor engagement terms and the scope agreed in writing before testing starts. | Implementation partners reviewing their own work, or internal teams presenting screenshots without the underlying configuration. |
| Recognized assessment body | NIST does not issue conformity assessments or certifications for CSF 2.0. Results come from the organization's own review or from an independent assessor it engages, and the report must say which. | A written statement of the assessment method and the assessor's qualifications, kept with the evidence. | Claims of NIST certification or endorsement in marketing or customer documents, which NIST does not provide. |
Implementing PR.PS-04 in order
This sequence takes log generation from an unknown set of sources to a tested pipeline that security monitoring can query. Each step produces a record an assessor can inspect, so the organization can show that logs are produced, transported, time-aligned and actually used.
Inventory every log-producing source
Start with a list of every operating system, application, network device, identity service and cloud service that can produce security-relevant events, including services that teams have deployed outside central IT. The owner of each system confirms the entry, and the security team reviews gaps against the asset inventory maintained under the ID.AM Category. The output is a source register that names each source, its owner, its environment and the event types it can emit. The step is complete when the register matches the asset inventory and no in-scope system is missing.
Set a logging baseline per source type
For each source type, such as Linux hosts, Kubernetes clusters, self-hosted applications and cloud control planes, define which events must be recorded, at what level of detail and with which fields, such as user identity, timestamp, source address and outcome. Security and platform engineering agree the baseline, and the owner of each source type signs it off. The output is a logging configuration baseline, version controlled like other configuration baselines. The step is complete when every source type in the register has an approved baseline.
Configure log generation on each source
Apply the baseline to each source, enabling audit logging in the operating system, the application or the cloud service's audit features. For self-hosted platforms, this includes turning on the built-in audit functions and confirming where they write. For example, an illustrative Nextcloud deployment would enable the admin_audit app and set the audit log path, and a team running OpenBao would enable an audit device. Confirm each setting against current vendor documentation, since defaults and option names change between releases. The output is a configuration change record for each source. The step is complete when a test action on each source produces the expected record.
Send logs securely to the central store
Forward records from each source to the logging infrastructure over encrypted, authenticated channels, and restrict who can read or alter the stored logs. Check that local log files are not the only copy, and that a source that stops sending is detected. The engineer running the change tests delivery by generating known events and confirming they arrive intact at the central store. The output is transport test records showing sent and received events with timestamps and integrity checks. The step is complete when every source in the register delivers its test events.
Synchronize clocks across all sources
Point every source and the central store at the same reliable time service so that events from different systems can be ordered and correlated during an investigation. Time synchronization software such as chrony can serve as a client of NTP servers or reference clocks, and as a time server for internal hosts. Record which time sources are used and check drift on a schedule. The output is a time synchronization configuration and a drift check record for each source group. The step is complete when all sources report synchronized time within the tolerance the baseline sets.
Verify that monitoring can query the data
Run the queries that detection and incident response teams will actually use against the stored logs, such as failed logins, privilege changes and configuration edits, and confirm that results return the expected fields. Include a test of alerting rules that depend on these logs. Monitoring staff perform the queries and the security lead reviews the results. The output is a monitoring query proof, a saved set of queries with sample results and the date each was run. The step is complete when each in-scope source type has been queried successfully at least once.
Document ownership and retention
Record who owns each log source, who may access the stored logs, how long each log category is kept and how it is disposed of. Retention periods should come from the organization's legal, regulatory and contractual obligations, and the organization should confirm them with its own counsel and assessor, not with an implementation partner. The output is a log ownership and retention standard, linked to the source register and the baseline. The step is complete when every source in the register has a named owner and an approved retention period.
Which evidence satisfies PR.PS-04 and how to keep it current
An assessor testing PR.PS-04 Log generation will ask whether logs are produced, sent securely and available for monitoring, and will look for records that prove each step. The cards below cover the artifacts that answer those questions and how to refresh each one between assessments so it reflects the systems as they run today.
Log source inventory
A current list of every operating system, application, network device and cloud service that should generate logs, with an owner and the log types each one produces. This is the starting point for any assessment, because a missing source is the most common gap an assessor finds. Reconcile the inventory against the asset inventory (ID.AM) each quarter and record which sources were added, retired or still unlogged. Confirm that cloud accounts and SaaS tenants appear, not only on-premises hosts.
Logging configuration exports
Exported configuration files from each source showing that audit logging is enabled and which event categories are captured. For a self-hosted application, this often means the server's own audit settings, such as the admin_audit app in Nextcloud writing to audit.log or to a path set with logfile_audit. Export these files on a schedule, store them in version control, and diff them against the previous export. Any change that disables a category should trigger a review.
Forwarder and transport records
Evidence that logs leave each source and reach the central logging infrastructure through a defined path, with transport encryption in place. Keep forwarder configuration exports, the destination addresses, certificate or key references (not the key material itself), and a record of which sources are sending. Check that logs are not silently dropped when a forwarder stops, and keep a sample of failed-delivery alerts. Refresh these exports at least quarterly and after any network change.
Time synchronization records
Proof that every log source uses a trusted time reference, so events can be ordered correctly during an investigation. Chrony can synchronize hosts with NTP servers or reference clocks and act as an NTPv4 server for other machines. Keep chrony configuration exports and tracking output showing offset and sync status from a sample of hosts, and confirm that the reference sources are documented. Sample a set of hosts each quarter to show time drift remains within the limit your own policy sets.
Sample log extracts for required events
Dated extracts from the central store showing that required events, such as authentication outcomes, privilege changes and administrative actions, were actually recorded and are searchable. Assessors usually ask for a sample drawn from a stated period, not a single hand-picked entry. Pull a defined sample each quarter, record the query used, and keep the extract with its hash or export time so it cannot be altered later. For secrets management platforms such as OpenBao, audit device logs record each API request and response with most sensitive values hashed, which can serve as a sample source.
Monitoring rules and change records
Two linked records: the alerting and correlation rules that consume the logs, and the change tickets that altered logging configuration. Assessors test whether a change to log settings was approved and whether it was reviewed after the fact. Keep rule exports with their last-modified dates, and match every logging change to a ticket that names the approver. A logging change without a ticket is a finding in most assessments, so reconcile tickets against the configuration diffs at each quarterly review.
What meeting PR.PS-04 costs in money and effort
This table breaks down the cost components of meeting PR.PS-04 Log generation, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request, since no price figures are supplied for these components and the real numbers depend on your environment. The main takeaway is that open-source licensing removes one line item, but engineering, storage and evidence work remain.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Logging platform licenses | Software vendor, if a commercial log platform is chosen | Recurring | Ingest volume and feature tiers; self-hosted open source avoids this line item but not operating effort |
| Engineering to configure log sources | Internal platform team or implementation partner | One-time, with later changes | Number of operating systems, applications and cloud accounts that must emit logs under PR.PS-04 |
| Secure transport and log forwarding setup | Internal engineers or implementation partner | One-time, then recurring upkeep | Number of hops, encryption requirements and whether logs cross network zones |
| Storage and retention capacity | Organization, through cloud or data center spend | Recurring | Event volume and the retention period set by policy, contract or regulation |
| Time sync and log integrity checks | Internal operations staff | One-time setup, recurring checks | Number of hosts that need consistent clocks, so log timestamps can be correlated |
| Evidence upkeep | Internal compliance or security staff | Recurring | Frequency of assessments and how many sources must show log samples on request |
| External testing or review | Independent assessor or security testing provider | Recurring or per engagement | Scope of testing and whether log coverage is tested alongside other outcomes |
| Auditor sampling time | Independent auditor or assessor | Recurring with each assessment | Number of systems sampled and how quickly complete log records can be produced |
| Self-hosted open-source software | Organization or its implementation partner for operations | Operating effort is recurring | Support model, upgrade frequency and in-house skills; the license cost is removed |
Self-hosted open-source tools that produce PR.PS-04 evidence
PR.PS-04 asks that log records are produced and made available for continuous monitoring. The three tools below cover different parts of that outcome: application audit trails, secrets-platform API records and the clock that timestamps every entry. Each card names what the tool writes, where the evidence sits and what your team must confirm before an assessor reviews it.
Nextcloud admin_audit application log
The admin_audit app records additional event information for a Nextcloud server, which is useful when an assessor asks who changed administrative settings and when. By default the events are written to audit.log in the data directory, or to a path you set with logfile_audit. Confirm that the file sits on a volume outside the web root, that its permissions block direct web access, and that a forwarder ships new lines to your central logging platform. Otherwise the evidence stays on the application host, where an attacker with server access can also edit it.
OpenBao audit device records
OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, which gives you a per-request trail for secrets and authentication activity. Most sensitive values are hashed with HMAC-SHA256, so the log supports investigation without exposing secret material in plain text. Confirm that at least one audit device is enabled before production use, that a failing audit device does not silently allow requests to proceed in your configuration, and that the file or socket destination is forwarded to tamper-resistant storage with a defined retention period.
chrony time synchronization
Log records are only useful for correlation when their timestamps agree, so PR.PS-04 evidence depends on accurate time. chrony synchronizes the system clock with NTP servers or reference clocks such as GPS receivers, and it can serve NTPv4 to other computers on your network. Typical accuracy is within milliseconds over the Internet and tens of microseconds on a LAN, according to the project. Confirm which upstream sources each host uses, that every log-producing system points to the same internal time source, and that chrony's tracking output is itself retained as evidence of synchronization.
Central log forwarding and retention
None of the three tools above is a log store, so the forwarding layer determines whether PR.PS-04 evidence survives an incident. Choose a self-hosted collector inside your own infrastructure, define which sources feed it, and document the transport protection used between each source and the collector. Ask your implementation partner to show the retention schedule, the access list for the log store and a test in which a deleted local file still appears in central storage. Each of these items becomes evidence an assessor can sample.
Who owns PR.PS-04 and what a partner can take on
Your organization owns PR.PS-04. That means deciding which systems and services must produce logs, what events matter for your risk profile, how long records are retained, who reviews them, and which monitoring use cases depend on them. These decisions follow from your asset inventory, your threat model and the legal or contractual duties you carry. No outside party can make them for you, and an implementation partner should not set them without your sign-off.
- Source scope: Decide which operating systems, applications, identity providers and cloud services are in scope, and record the reason for each.
- Event requirements: Define the minimum events each source must generate, such as authentication, administrative changes and access to sensitive data.
- Retention and access: Set retention periods and state who may read, export or delete log records.
- Monitoring use: Name the detections and reviews that rely on these logs, so the scope is tied to outcomes.
- Ownership record: Assign a named owner for each log source and keep the decisions in a version-controlled document.
Confirm that these decisions are approved by the accountable control owner and that they match the policies your assessor will read.
An implementation partner can take on the technical work that turns your decisions into running systems and evidence. DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not decide your logging scope, and it does not issue audit reports or certifications. Work is normally fixed-scope, with deliverables agreed in writing before work starts.
- Source configuration: Enable logging on platforms such as Nextcloud, where the
admin_auditapp writes to a log file set bylogfile_audit, and confirm each source writes the events you specified. - Forwarding and transport: Set up forwarding to your logging infrastructure over protected channels, and synchronize clocks with chrony so timestamps can be correlated.
- Evidence exports: Build repeatable exports or reports that show which sources log, what they record and where records are stored.
- Query testing: Verify that monitoring tools can search and alert on the data, and document the results.
- Handover: Deliver runbooks, configuration records and test results to your team.
Ask the partner to state in the scope which items it configures, which it only documents, and which remain with your staff.
An independent auditor, assessor or certification body tests whether PR.PS-04 is met and issues any report or certificate. The assessor reviews your documented scope, samples log sources, inspects configurations and evidence, and checks that monitoring actually uses the data. Because the assessor judges the work, it must stay independent of anyone who configured the systems. Where a partner built the logging, the assessor can still review it, but must form its own conclusions from the evidence.
- Independence: Confirm the assessor has no role in designing, configuring or operating the logging systems it tests.
- Sampling: Expect the assessor to select sources and time periods and ask for the records themselves, not summaries.
- Integrity checks: Expect questions on who can alter or delete logs, and how transport and storage are protected.
- Tracing: Expect requests to follow a sample event from source to monitoring alert.
- Reporting: Only the assessor issues the findings, and the organization decides how to respond to them.
Before engaging an assessor, ask how it handles conflicts of interest and whether it has reviewed any part of the logging design.
PR.PS-04 questions buyers ask before hiring help
How much effort does PR.PS-04 take in a typical mid-sized environment?
The effort depends mainly on how many log sources you have and how many of them already send events somewhere. PR.PS-04 asks that log records are generated and made available for continuous monitoring, so the work splits into two parts: configuring each operating system, application and cloud service to produce useful records, and building the secure path that moves those records to your logging infrastructure. A small estate with a few servers and one cloud account is a very different job from dozens of applications spread across hybrid networks. NIST publishes no effort figure for this subcategory, so ask any provider for a written inventory of log sources, the logging standard they will apply, and an effort estimate broken down by source type. Treat an estimate that does not show that breakdown as unverified.
Can our internal team implement PR.PS-04 without an outside partner?
Often yes, if you have engineers who already run your logging platform and understand your applications. The work is mostly configuration, transport and testing, which in-house teams can do. Outside help is most useful where log sources are unfamiliar, where the transport must be encrypted and authenticated across network zones, or where the team lacks time to document the result. Whichever route you choose, the organization owns the outcome: it decides which events matter, which retention period applies and who reviews the records. Ask a partner to state in writing which log sources it will configure, which it will only document, and which remain with your staff.
What does PR.PS-04 need from our internal staff?
Your staff needs to supply knowledge that no outside party can infer from the environment alone. That includes the owners of each system, the events that matter for investigations, the regulatory retention obligations that apply to your data, and the people who will review alerts once logs arrive. Your team also needs access to change approvals and maintenance windows, because enabling verbose logging can affect performance and storage. Plan named owners for the logging infrastructure and for each log source. Before any work starts, ask for a list of the internal roles the engagement depends on and the hours each role must commit.
How long does PR.PS-04 take, and what sets the timeline?
No fixed duration applies to PR.PS-04, and any figure a provider gives should come with its assumptions. The timeline is set by the number of log sources, the state of existing logging, the complexity of network paths between sources and the logging platform, and how quickly change approvals and testing can happen. Delays commonly come from unclear ownership of systems, legacy applications that cannot change their logging behavior, and retention or access rules that need legal review. Ask for a schedule with milestones per log source group, a list of dependencies on your side, and a clear statement of what counts as done.
What should a written scope for PR.PS-04 include?
A useful scope names the systems in or out, the log types to generate for each, the secure transport method, the destination logging infrastructure, the time synchronization approach and the evidence you will receive. Clock accuracy matters because records from different systems must line up during an investigation, and chrony is one open-source option for synchronizing system clocks with NTP servers or reference clocks. Require the scope to say who configures each system, who tests that records arrive intact and who signs off. Fixed-scope agreements with clear deliverables make it easier to compare offers.
Does NIST certify that our log generation meets PR.PS-04?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Any provider or tool that claims to certify PR.PS-04 compliance is making a claim NIST does not support. What you can obtain is evidence: configuration records, sample log entries, transport settings and test results that an independent assessor can review. Only an independent auditor or assessor issues a report or attestation. Ask providers to describe the evidence they will hand over, not a certificate they cannot issue.
Which evidence should we expect at the end of a PR.PS-04 engagement?
Expect records that show what is logged, where it goes and how you know it arrives. Typical items include a log source inventory, configuration exports for each system, examples of generated entries, documentation of the secure transport, time synchronization settings and a test log showing end-to-end delivery. Where a source already writes its own audit trail, such as Nextcloud's admin_audit app writing to audit.log, the evidence should show where that file lives and how it reaches the central platform. Ask the provider to list every artifact in writing before the work begins.
How DeployOpen scopes and prepares PR.PS-04 evidence
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, then prepares the log generation, secure transport and retention evidence that PR.PS-04 calls for. The organization owns its controls, and only an independent auditor or assessor reaches a conclusion on them.
How we scope
- Engagements are fixed-scope, with systems, log sources and deliverables agreed in writing before work starts.
- The written scope lists which operating systems, applications and cloud services must generate logs for PR.PS-04.
- We confirm the logging infrastructure that receives records and who in your organization owns it.
How we build
- We configure log generation on in-scope systems and verify that events are recorded as the scope describes.
- Log transport is set up to send records securely to your central logging infrastructure, with encryption and access controls checked.
- Clock synchronization is configured on each source so timestamps in logs can be compared and relied on during reviews.
How we hand over
- We document the log sources, configuration settings and transport paths so your team can reproduce and review them.
- Test records and configuration exports are packaged as evidence for your assessor, mapped to the PR.PS-04 outcome.
- Your organization receives the documentation and runbooks, and decides which evidence to present to its auditor.
How we support
- Ongoing support, upgrades and continuous testing of logging configuration are available as a retainer.
- Retainers can cover reviewing log source changes when new systems or cloud services are added to scope.
- Confirm with us in the quote which support items recur and which are one-time, before the engagement begins.
