Logging & Monitoring Policy

1. Purpose

This policy sets out what Subcontext logs, how long logs are kept, how they are protected and how they are monitored. Good logging lets Subcontext detect and investigate security incidents and faults, show customers and regulators what happened and who did it, and keep the platform available. Logs can themselves contain personal data, so this policy also makes sure they are kept only as long as needed and protected like the data they describe.

2. Scope

This policy covers:

• The Subcontext platform in production: the web application, background workers, database, cache, file storage, load balancer, web application firewall and network
• Logs and records kept by the application, including the audit log and compliance decision trail
• Infrastructure logs and alarms in AWS
• Error monitoring and performance monitoring

3. Definitions

4. What Is Logged

4.1 Audit log detail

The audit log covers around 330 types of event across the platform, such as changes to users, settings and integrations. Each entry records:

• Who acted, and the Subcontext administrator acting on their behalf where an administrator is impersonating a user
• What was done, and to which record
• When it happened
• The IP address, browser (user agent) and request it came from

When a Subcontext administrator starts or stops impersonating a customer's user, that is itself recorded, and every action taken while impersonating records the administrator.

4.2 Compliance decision trail detail

• The trail is kept for 6 years by default, and customers can set a period between 3 and 25 years
• Entries are hash-chained, so each entry depends on the one before it, and the chain is sealed every minute
• The trail refuses to be purged if its hash chain has been broken

4.3 What must not be logged

The following must never be written to logs in readable form:

• Passwords, one-time codes and backup codes
• Access tokens, API keys, session identifiers and other secrets
• Card details, which Subcontext never receives, and Direct Debit bank details
• Values given to AI agent tools that are marked sensitive

5. Protecting Logs

• Audit log entries cannot be altered once written
• The compliance trail refuses to be purged if its hash chain has been broken
• Passwords, tokens, one-time codes and other sensitive values are filtered out of logs
• Sensitive values given to AI agent tools are recorded as redacted
• Access to logs is limited to the people who need it

In addition:

• Logs are classified as Confidential under the Data Classification Policy, because they can contain personal data
• Infrastructure logs are held in AWS, which is accessed only by named members of the team
• Customers see the audit log for their own organisation only
• Logs are deleted automatically when their retention period ends, in line with the Data Retention & Deletion Policy

6. Monitoring and Alerting

• Application errors alert the engineering team by email the first time they occur, if they recur after being resolved, and as their count grows
• Infrastructure alarms cover the database, cache, load balancer and application servers
• The web application firewall blocks known-bad traffic and rate-limits abusive clients automatically
• A daily heartbeat message to the team confirms that scheduled processing is running
• Health checks remove unhealthy application servers automatically

6.1 Monitoring in detail

6.2 Areas for development

At each review of this policy, Subcontext will consider whether to add a cloud-wide audit trail of infrastructure changes and a managed threat detection service, taking account of the growth of the platform and customers' assurance needs.

7. Responding to Alerts

1. The person receiving the alert acknowledges it and checks whether it is genuine
2. Faults are fixed and the error is resolved in the error monitoring tool, so that a recurrence alerts again
3. Anything that may indicate a security incident, such as unexpected administrator activity, a spike in blocked requests or signs of unauthorised access, is handled under the Incident Response Plan
4. Where logs are needed as evidence, the relevant entries are preserved before their retention period ends

8. Roles and Responsibilities

9. Review

• Alerts are investigated promptly, and handled under the Incident Response Plan where they indicate an incident
• Administrator activity in the audit log is reviewed periodically

In addition:

• Administrator activity, including impersonation of customers' users, is reviewed at least quarterly
• Alarm thresholds and alert recipients are reviewed at least annually, and after any incident where monitoring did not detect a problem promptly
• This policy is reviewed at least annually

10. Related Documents

• Information Security Policy
• Incident Response Plan
• Access Control Policy
• Data Classification Policy
• Data Retention & Deletion Policy
• Vulnerability Management Policy
• Business Continuity & Disaster Recovery Policy

11. Document Control