1. Log sources
| Source | Content | Where | Retention |
|---|---|---|---|
| Audit log (application) | Security-relevant events, one hash-chained sequence per organization plus one for the platform | PostgreSQL table audit_events |
See section 4 |
| Application log | Errors and warnings | Daily files on the server | 14 days (automatic rotation) |
| Web server log | HTTP requests (IP address, time, path, status) | Caddy log file on the server | Not yet configured (section 4) |
| System logs | SSH logins, fail2ban bans, package updates | Ubuntu journal and /var/log |
Ubuntu defaults |
2. What the audit log records (in place)
Each event records: organization, actor type and ID, action, subject, context, IP address, browser user agent, UTC timestamp with microseconds, the previous event's hash and its own SHA-256 hash.
Events include:
- Authentication: login, failed login, lockout, logout, MFA enrolment, MFA success and failure, recovery-code use, MFA reset, password change.
- Access and keys: organization creation, member added and removed, organization data export, API key creation and revocation, phone number change.
- Configuration: agents, tools, channels, credentials (reference only), catalog, policies and policy versions, activation and automatic reverts, inventory import, protection plans, organization settings and badge.
- AI-agent decisions: every allow, deny and approval-required decision, approvals opened, used and refused, and actions executed without authorization.
- Cases and reports: case opening and status, retests, dossiers, reports, remediation proposals and pull requests.
- Public site: leads received.
- Integrity checks: each audit-chain verification.
Never logged: passwords, MFA secrets, API tokens or other secrets. Agent action parameters are masked before storage (tax IDs, e-mails, phone and card numbers masked; password, token, secret, API key, authorization and cookie fields removed; long text cut).
3. Protection of the audit log
- In place: the table is append-only - a database trigger blocks UPDATE, DELETE and TRUNCATE. Each event is chained to the previous one by SHA-256, and the chain is verified automatically every 10 minutes and at the end of every deploy. Customers can check their organization's chain in the panel.
- Known limit: the application's database role currently owns the table, so someone with that role or a database superuser could disable the trigger and rebuild the chain.
- In rollout: separate database roles so the application can only insert and read (owner: Founder, target 2026-10-15), and a daily anchor that records the head of each chain outside the database, so that verification detects a rewritten history (owner: Founder, target 2026-10-15). Copying the anchors off the server is part of the off-site backup commitment (policy 06).
- Commitment: include the audit log in the off-site encrypted backup (policy 06, target 2026-10-31).
4. Retention
- Audit log: kept for as long as the customer organization exists, because it is the customer's evidence. After the contract ends it is kept for up to 5 years as evidence of what happened, then deleted, unless a legal hold applies. The deletion procedure (run by the Founder, recorded in the register) is a commitment: owner Founder, target 2026-12-31.
- Application log: 14 days.
- Application access records (in place): Brazilian law (Marco Civil da Internet, art. 15) requires internet application providers to keep access records (date and time of use from a given IP address) for 6 months. Every sign-in, failed sign-in and logout is written to the append-only audit trail with the IP address and UTC time, as is every other authenticated security event. The audit trail is not purged, so these records are kept for at least 6 months - in practice for the life of the account and the audit-log period above.
- Web server (Caddy) access log: its retention is not yet configured; we do not rely on it for the 6-month obligation. Commitment: set Caddy log rotation to keep between 6 and 12 months and record the setting (owner: Founder, target 2026-10-15).
- Retention of other data is set in policy 08.
5. Access to logs
- Inside the product, the audit log is visible only to users whose role has the audit permission, and only for their own organization.
- Server logs and the database are accessible only to the Founder through SSH (policy 01).
- Commitment: record in the audit log each time someone opens or exports the audit log (owner: Founder, target 2026-12-31).
- Logs are handed to third parties only under policy 08 (law enforcement requests) or to the affected customer.
6. Time synchronization (in place)
The server clock is synchronized by NTP. All timestamps in the database and the audit log are stored in UTC; the interface only converts them for display.
7. Monitoring and alerts
In place: automatic audit-chain verification (result shown in the panel); fail2ban on SSH; automatic security updates; Hostinger's server-side malware scanner (Monarx) runs on the VPS - who receives its alerts is to be confirmed.
Not in place (disclosed): there is no automated alerting today. Nobody is paged if the site goes down, the disk fills, the scheduler stops or the audit chain fails verification.
Commitments (owner: Founder):
- External uptime monitor on the site and API with e-mail and phone alerts (target 2026-10-31).
- Alert when audit-chain verification fails or the scheduler stops running (target 2026-10-31).
- Alerts on disk, memory and CPU thresholds (target 2026-11-30).
- Daily summary of security events: failed-login spikes, lockouts, MFA failures, fail2ban bans (target 2026-12-31).
8. Review
- Until alerts exist, the Founder checks the panel's audit-chain status and the server's fail2ban and update status at least weekly, and records anomalies in the register.
- Anomalies are handled as potential incidents under policy 05.
- The logging scope in this document is reviewed at least once a year and when the threat picture changes.