PR.PS-04 says log records are generated and made available for continuous monitoring. Detection depends on data. If a system does not log, or logs stay trapped on the machine that produced them, no one can spot trouble or investigate it afterward.
CSF is voluntary guidance. There is no CSF certification.
What good looks like
Operating systems, applications, and cloud services are all configured to write security relevant logs. Those logs are shipped securely to central storage that the people who monitor can read and attackers on the source host cannot easily alter. The logs capture the fields you need: who, what, when, from where, and the outcome.
How to implement it
- List your log sources: identity provider, cloud control plane, endpoints, servers, databases, applications, network and email security tools.
- For each source, turn on audit logging. Many cloud services have it off by default.
- Forward logs to one place, such as a log platform or a SIEM. Use encrypted transport and restricted write access.
- Standardize time sources so events line up across systems.
- Set retention that matches your investigation needs and contractual obligations. Ninety days searchable and a year archived is a common starting point.
- Check weekly that every source is still sending. A silent source is a finding.
- For zero trust style designs, confirm logs include the identity and device details the policy engine needs.
A worked example
A team believes it has good logging because its application writes detailed logs. During an investigation into a suspicious login, they discover the identity provider keeps audit events for only thirty days and that cloud audit logging was never turned on in a secondary account. The activity they need to see is gone.
The remedy is a log source inventory. For each source, record whether audit logging is enabled, where it goes, how long it is kept, and who checks that it still arrives. Ten rows in a spreadsheet are enough to start.
What a useful log record contains
A record should answer who did what, to which object, when, from where, and what happened. Time stamps should use a common standard and synchronized clocks. User identity should be a stable identifier. For zero trust style designs, include the device and session context the access decision relied on. Avoid putting secrets or full personal data into logs, and protect the logs themselves from tampering by limiting who can write and delete.
Silent failure is the real risk
Log pipelines break quietly: an agent crashes, a token expires, a quota is hit. Add a check that alerts when any source sends nothing for an unusual period. Review the list of silent sources weekly. This single control prevents most unpleasant surprises during incidents.
Cost and volume
Logging everything forever is expensive. Decide which sources get full detail and long retention, such as identity and cloud audit logs, and which get summaries or shorter retention. Revisit the decision yearly as your needs and prices change.
Evidence to collect
- Log source inventory with status.
- Screenshots or configs showing audit logging enabled.
- Retention settings.
- A report of sources that stopped reporting and how fast they were fixed.
Common gaps
Cloud audit trails never enabled. Application logs that omit user identity. Logs stored only on the host. No alert when a source goes quiet. Retention too short to cover a slow intrusion.
Quick check
Is collecting logs the same as monitoring?
No. PR.PS-04 is about making logs exist and available. The analysis happens in the DETECT outcomes such as DE.AE-02 and DE.AE-03.
Sources
- NIST Cybersecurity Framework 2.0 (NIST CSWP 29), PR.PS-04 and its implementation examples.
