Skip to content

SC.07 — Logging and Monitoring#

System: AI Connectors Platform Last updated: 2026-04-29

This document describes how the AI Connectors platform fulfils the SC.07 control category.

Control Attestation Table#

Control Description Status Evidence
CTRL0537487 — SC.07.01 Define the security monitoring and logging requirements Compliant logging-monitoring.md §1 (Log Requirements), §2 (Audit Log Format), §3 (Application Log Format)
CTRL0537513 — SC.07.02 Review logs on a periodic basis Compliant logging-monitoring.md §8 (Log Review Process)
CTRL0537527 — SC.07.04 Ensure that log files cannot be tampered with Compliant logging-monitoring.md §6 (Log Integrity and Tamper Protection)
CTRL0537515 — SC.07.06 Determine which IT components require monitoring Compliant logging-monitoring.md §1 (Log Requirements table), §7 (Monitoring and Alerting)

Security Controls Reference#

CTRL0537487 — SC.07.01: Define the security monitoring and logging requirements#

Control Text: Based on risk, define the security events that must be logged and establish a process for review of these. Relevant events to consider include: (i) creation, modification, or deletion of data; (ii) system configuration settings; (iii) creation, change and cancellation of access authorisation; (iv) successful/unsuccessful login attempts including date/time and UserID; (v) activities performed by privileged users; (vi) use of temporary access keys/tokens; (vii) changes to cryptographic keys or other secrets.

Applicability: Basic IT security requirement.

Additional Description

As part of the risk assessment and system design, determine the purpose for which logs are created, what data is collected, and any requirements for protecting log data.

Each log event should include, as applicable: - User IDs, system activities, dates and times - Device identity, system identifier and location - Network addresses and protocols

Events to consider for monitoring unusual activities: - Successful and rejected system/data access attempts - Changes to system configuration and use of privileges - Files accessed and type of access, including deletion of important files - Creation, modification or deletion of identities - Activation/de-activation of protection systems (e.g. antivirus, intrusion detection) - Unusual or risky user activity (e.g. shift in activity pattern)

Log retention: The retention period should reflect identified risks. Note that incidents are empirically not discovered until after 6–8 months. The GID Log Collection service should not be considered a log retention service — IT Solution Managers remain responsible for ensuring log retention is agreed with the vendor managing the servers.

Detailed Description

The platform captures all security events required by SC.07.01 through a multi-layered logging architecture. Every MCP tool invocation generates a mandatory NDJSON audit record written to S3 via Kinesis Firehose, containing user identity (Azure AD OID and UPN), tool name, parameters, outcome, timestamp, and duration. Application logs flow to CloudWatch capturing authentication failures, HTTP errors, and operational events. AWS CloudTrail audits all infrastructure API calls including secret reads, IAM changes, and ECS deployments. Retention periods align with security requirements: S3 audit logs 365 days, CloudWatch 30 days, CloudTrail 90 days. All timestamps use UTC to enable cross-system correlation during incident investigations.

Implementation Considerations

CTRL0537513 — SC.07.02: Review logs on a periodic basis#

Control Text: Review logs on a periodic basis according to the defined log requirements.

Applicability: Basic IT security requirement.

Additional Description

Once log requirements are defined (per SC.07.01), logs must be reviewed at the defined frequency. Document all log review activities, including: - Which logs were reviewed - Results of the review - Any incidents identified

Detailed Description

The IT Infrastructure Manager conducts monthly log reviews covering all production MCP servers. Reviews query S3 audit logs via the /check-audit-logs skill, examine CloudWatch alarm history, and filter application logs for ERROR-level events. The review identifies security patterns including repeated errors from the same user, spikes in redacted outcomes, authentication failure clusters, and permission denials. All reviews are documented in dated exports at docs/compliance/log-reviews/ containing summary statistics, triggered alarms, identified incidents, and remediation actions. Real-time CloudWatch alarms supplement monthly reviews by sending SNS notifications when thresholds are breached, enabling immediate investigation of active incidents.

Implementation Considerations

CTRL0537527 — SC.07.04: Ensure that log files cannot be tampered with#

Control Text: Ensure that log files cannot be subject to unauthorised changes and that logs are available when relevant, preferably for a time period equal to that of the user review.

Applicability: Basic IT security requirement.

Additional Description

Users, including those with privileged access rights, should not have permission to erase or deactivate logs of their own activities. Controls should protect against: - Alterations to the message types that are recorded - Log files being edited or deleted - Storage capacity being exceeded, resulting in failure to record events or overwriting of past records

Techniques to consider for log protection: - Cryptographic hashing - Recording in an append-only and read-only file - Recording in a public transparency file

Note that event logs can contain sensitive data and PII — appropriate privacy protection measures should be taken.

Detailed Description

Audit logs are protected from tampering through S3 bucket policies that explicitly deny delete operations for all principals including root users, creating an immutable audit trail. S3 versioning preserves original records if overwrite attempts occur, and the bucket policy denies version deletion. IAM policies enforce least privilege — Kinesis Firehose has write-only access, ECS tasks have no bucket access, and review roles have read-only access. Audit writes occur in application finally blocks guaranteeing emission regardless of errors. CloudTrail logs all infrastructure changes to the audit system itself, providing a meta-audit trail. CloudWatch application logs are protected via IAM policies that prevent ECS tasks from deleting log streams.

Implementation Considerations

CTRL0537515 — SC.07.06: Determine which IT components require monitoring#

Control Text: Determine which IT components and the type of log events which should be monitored, and how, in order to discover unauthorised activity in the IT Solution. Ensure events are monitored on a regular basis.

Applicability: Basic IT security requirement.

Additional Description

Event logging forms the foundation for automated monitoring systems capable of generating reports and alerts on security events. All systems should share the same time source to allow correlation of logs across systems during incident investigations.

To implement log monitoring in practice:

  1. Determine the IT components and log event types to monitor (see SC.07.01).
  2. Choose a log monitoring tool suited to the organisation's needs. On cloud platforms, consider using the platform provider's native monitoring service.
  3. Configure the tool to monitor the identified components and events, and set up alerts and notifications for suspicious activity.
  4. Act immediately on any suspicious activity detected — investigate and remediate (e.g. disabling user accounts, blocking IP addresses).

Detailed Description

The platform monitors application, infrastructure, and authentication layers using CloudWatch as the primary tool. Each MCP server has four CloudWatch alarms detecting authentication failures, error rate spikes, HTTP 4xx/5xx anomalies, and publishes notifications via SNS. ECS service health is verified through ALB health checks every 15 seconds that test FastMCP responsiveness and dependency reachability. AWS Security Hub aggregates findings from AWS Config (configuration drift), GuardDuty (threat detection), and Inspector (container vulnerabilities), with high-severity findings escalated to IT Infrastructure Manager. All monitoring sources use UTC timestamps enabling cross-system correlation during investigations.

Implementation Considerations