Method
How an event earns its tier. The criteria and every threshold were fixed before any role count was made, and each row records which criteria it met.
The three criteria
An event is in the minimum set for a role when it meets C1 and at least one of C2 or C3. It is recommended when it meets any one of the three. Otherwise it is listed. An event that cannot occur on a role is not applicable there, and is excluded rather than shown.
- C1, ATT&CK. At least one ATT&CK analytic names the event in its log-source rows.
- C2, a standard or guidance names it for the role. A DISA STIG audit rule in the role's scope requires its subcategory or policy; or NSA's Event Forwarding Guidance lists it; or Microsoft's Appendix L rates it High or Medium; or Microsoft's per-device audit baseline says yes for the role's device type; or the CISA and ASD best-practice guidance or CISA's M365 playbook names it; or, for web roles, the web shell guidance, CISA CM0106 or the OWASP logging cheat sheet names the log.
- C3, rules. At least the platform's threshold of vendor prebuilt rules declare an explicit dependency on the event.
Thresholds
| Platform class | Rules needed | Counted |
|---|---|---|
| windows | 10 | C3: at least this many vendor rules must explicitly depend on the event |
| linux | 5 | C3: at least this many vendor rules must explicitly depend on the event |
| macos | 5 | C3: at least this many vendor rules must explicitly depend on the event |
| cloud | 3 | C3: at least this many vendor rules must explicitly depend on the event |
| web | 3 | C3: at least this many vendor rules must explicitly depend on the event |
| network | 3 | C3: at least this many vendor rules must explicitly depend on the event |
| identity | 3 | C3: at least this many vendor rules must explicitly depend on the event |
| containers | 3 | C3: at least this many vendor rules must explicitly depend on the event |
| edr | 10 | C3: at least this many vendor rules must explicitly depend on the event |
| other | 3 | C3: at least this many vendor rules must explicitly depend on the event |
| log-level | 10 | L3: at least this many vendor rules must depend on the log source in any way (explicit, source_only or inferred) |
Logs tiered as a whole
For cloud accounts, tenants, identity providers, Kubernetes, container hosts, network sensors and ESXi, the log is what an organization turns on, so each log is also tiered as a whole: L1 when an ATT&CK analytic names the log, L2 when a standard names it, L3 when at least ten vendor rules depend on it in any way. Minimum needs L1 and one of L2 or L3; recommended needs any one. The per-event rows remain and say which operations within a log carry the detections.
Three kinds of logging requirement
Three kinds of logging requirement. Authorities ask for logs in three ways, and the words matter. A direct requirement names the events and often the numbers: PCI DSS says which logs are reviewed daily and how long they are kept. An outcome-based requirement says what logging must achieve and leaves the how to you: HIPAA asks you to record and examine activity; NIST 800-171 asks you to set the events and the review frequency yourself. A records or evidence requirement is about keeping records of a certain kind for a certain time, and logs are one way to produce them: SEC 17a-4 and FDA Part 11 work this way.
A SIEM is almost never mandated by name. Of the fifteen authorities here, none requires a product called a SIEM. They require that logs exist, are reviewed on a cadence, are kept for a period and are protected. Many organizations meet that with a SIEM; some meet it with log management and scheduled review. The log panel above shows what each choice would collect either way.
The questionnaire's optional compliance stage matches what you describe to the authorities in this reference and shows their own words for events, review and retention, each read from its primary source on the date the card gives. It never says an authority applies to you.
Where the dependencies come from
- ATT&CK: technique, to detection strategy, to analytic, to the log-source rows that name a channel and event.
- Splunk: each detection's data-source names, resolved through the repository's own definitions.
- Sigma: the rule's log-source category, mapped through the Sigma taxonomy; service rules by their event ID.
- Elastic: index patterns and data-source tags give the source; an explicit event code gives the event; a category alone gives an inferred event, which does not count toward C3.
- Microsoft Sentinel: the rule's required data connectors and the event, operation and action filters in its query.
Only metadata from these repositories is reproduced. No rule query appears on these pages.