Compliance

Overview → Compliance (/compliance) shows, for each framework your organisation reports on, the controls the platform holds evidence for, and exports that evidence as a ZIP file for an auditor. It also says how long logs are kept, and warns when that is shorter than a chosen framework expects.

The page shows where the platform produced evidence for a control. It is not an audit opinion.

Who can use it

Action	Who
Read the page and open a control	Administrators, Security Analyst and Security Viewer (the page's default grants; see Users and roles)
Choose frameworks	Administrators
Export the evidence pack	Administrators. Every export is recorded in the audit log
Change how long logs are kept	Administrators, in Admin → Integrations → Data retention

Frameworks

Framework	Evidence from alerts	Evidence from configuration checks
SOC 2	yes (Trust Services Criteria)	yes
HIPAA	yes	yes
PCI DSS	yes	yes
GDPR	yes	yes
NIST 800-53	yes	yes
ISO 27001	no: the detection rules do not tag its controls	yes

No framework is chosen on a new stack.

Choose the frameworks you report on

1. Open Compliance and choose Choose frameworks.
2. Turn on each framework you report on.
3. Choose Save frameworks.

The choice changes only what this page shows; nothing on the stack changes. It is recorded in the audit log. With more than one framework chosen, the page has a tab for each.

Read a framework's controls

The header sentence sums up the framework, for example SOC 2: 41 controls with activity in the last 90 days, 3 with failing configuration checks on 5 machines.

Choose the period with the Last 90 days menu: 7, 30, 90, 180 or 365 days. The default is 90.

Each row is a control:

Column	Meaning
Control	The control's id in the framework
Description	A short reference title. It is not the standard's text. A control without a title on file shows No title on file
Alerts	Alerts the detection rules tagged with this control in the period
Failing checks	Configuration checks that support this control and fail now on the reporting machines. Rows with failing checks are highlighted
Machines	The machines behind the alerts or the failing checks
Last event	When the last tagged alert arrived

Where the evidence comes from:

• Alerts. Each detection rule can tag its alerts with the controls they are evidence for. The page counts them over the period you chose.
• Configuration checks. The agents run security configuration benchmarks (CIS) on each machine, and each check names the controls it supports. The page shows the checks failing now, whatever the period. They are read again every 10 minutes, from at most 300 machines; when there are more, the page says so. The line under the table says how many machines were assessed and when.
• Disabled agents are left out of both, as everywhere in the console (Disable).

When a list is empty for the period, a longer period may show more.

Open a control

Choose a row. A panel opens with the control's evidence over the period:

• Alerts, Failing checks and Last alert;
• Rules that produced the alerts: rule, description, level and count;
• Machines: each machine's alerts and last alert;
• Failing configuration checks: machine, check and benchmark;
• Recent events, with the log line where there is one.

Evidence pack

1. Choose the period with the Last N days menu. The pack covers the same period.
2. Choose Export evidence pack.
3. Your browser saves athena-evidence-YYYYMMDD-Nd.zip, for example athena-evidence-20261031-90d.zip. The page confirms the export and records it in the audit log.

The ZIP holds CSV files that open in any spreadsheet:

File	Content
README.txt	Organisation, when and by whom it was made, period, frameworks, log retention (and any shortfall, below), the files, and anything that could not be read
controls.csv	Per framework and control: alerts and machines in the period, and the failing configuration checks now
configuration_checks.csv	Every configuration check failing now on the reporting machines, with the controls it supports
configuration_scores.csv	Each machine's benchmark score now
audit_trail.csv	What people did in the console in the period: sign-ins, changes, responses. Page views are left out; at most 50,000 rows
vulnerabilities_fixed.csv	Vulnerabilities fixed in the period, with the verification engine's proof
patch_activity.csv	Patch approvals, rejections and runs in the period (at most 1,000 events)
user_access.csv	Who can sign in to the console: roles, administrator flag, whether the account is active, last sign-in

A part that cannot be read is exported as an empty file and listed under Not included in the README: the export does not fail because of it. A cell that starts with =, +, - or @ is prefixed with ' so that a spreadsheet does not run it as a formula.

Data retention

The stack keeps alerts and network events for a set number of days, then deletes the oldest days. The default is 45 days; it can be set from 7 to 3650.

The Compliance page shows the period and the disk it takes, for example Logs are kept 45 days (the default). 12 GB stored over 31 days; 45 days need about 18 GB. The estimate is the average size of a stored day times the retention days. Check it, and the free disk on the server that holds the alerts, before you raise the period.

Change how long logs are kept

1. Open Admin → Integrations → Data retention (or Change retention on the Compliance page).
2. Set Keep logs for (days).
3. Choose Save.

The stack applies the change within a minute and records it with your provider, like any other integration (Set up an integration). Lowering the period deletes the days older than the new period.

When the period you choose on the Compliance page is longer than the retention, the page says that the period starts where the stored logs do.

When logs are kept shorter than a framework expects

Each framework expects logs to be kept for a period:

Framework	Expects	Basis
PCI DSS	365 days	A requirement: 10.5.1, 12 months, the last 3 immediately available
SOC 2	365 days	A guideline: a SOC 2 Type II audit covers up to 12 months
HIPAA	365 days	A guideline: the audit controls standard, 164.312(b); HIPAA itself keeps documentation 6 years
NIST 800-53	365 days	A guideline: AU-11, as most baselines set it
ISO 27001	365 days	A guideline: A.8.15 logging, with the period the organisation sets
GDPR	none	GDPR sets no minimum, so there is no check

When the retention is shorter than the framework on screen expects, the page shows a warning, for example Logs are kept 45 days; SOC 2 audits usually expect 365, or Logs are kept 45 days; PCI DSS requires 365. It says whether the period is a requirement or a guideline, and where it comes from.

• Administrators get Change retention, which opens Admin → Integrations → Data retention.
• Other users are told that an administrator changes it there.
• The evidence pack's README.txt names the shortfall under Log retention, for each chosen framework that expects more.

To clear the warning, set Keep logs for (days) to at least 365. Check the disk estimate first: a year of logs needs about eight times the disk of the 45-day default.