Logging, Auditing & Tamper-Evident Trails

Executive Summary

Proving What Happened and When

Audit logging is the evidence layer of enterprise security. When a SOC 2 auditor asks "how do you know who accessed what data and when?", audit logs are the answer. When an enterprise client's CISO asks "can you prove that no unauthorized person saw our coaching data?", audit logs are the proof. When a security incident occurs, audit logs are the forensic record.

ReGenesis implements comprehensive audit logging across five domains: authentication events (who logged in/out and when), data access events (who viewed which records), data change events (who modified what and the before/after state), system and AI action events (what Sasha processed and why), and administrative action events (user management, configuration changes). All logs are centralized, tamper-evident (Write Once Read Many storage), retained for a minimum of one year, and available to enterprise admins through a self-service audit UI.

This is not optional for enterprise sales. SOC 2 CC7.1 (monitoring), ISO 27001 A.8.15 (logging), and virtually every enterprise security questionnaire require demonstrable audit capabilities. For the McKinsey pilot, authentication and data access logging must be operational. For GA, the full audit suite including the enterprise admin UI must be production-ready.

Working Knowledge

What Gets Logged

Five Categories of Audit Events

What Each Log Entry Contains

Every audit event captures a consistent set of fields:

Field	Description	Example
event_id	Unique identifier	evt_a1b2c3d4e5f6
timestamp	UTC timestamp (ISO 8601)	2026-06-15T14:30:22.456Z
event_type	Category and action	auth.login_success
actor_id	User or system ID performing the action	usr_abc123
actor_role	Role of the actor	coach
actor_ip	IP address	203.0.113.45
actor_user_agent	Browser/device info	Mozilla/5.0...
tenant_id	Organization	ten_mckinsey
resource_type	What was acted upon	coaching_session
resource_id	ID of the resource	ses_xyz789
action	What happened	view
visibility_tag	Data visibility level accessed	coach_only
result	Outcome	success or denied
metadata	Additional context	{ "reason": "session_timeout" }
before_state	Previous value (for changes)	{ "status": "active" }
after_state	New value (for changes)	{ "status": "completed" }

Log Storage and Retention

Aspect	Implementation
Centralized Storage	All logs flow to a single platform (CloudWatch + S3)
Tamper Evidence	Logs written to WORM (Write Once Read Many) S3 storage with Object Lock
Retention Period	Minimum 1 year for standard logs; 3 years for security events; 7 years for billing
Encryption	Logs encrypted at rest with AES-256 (KMS-managed keys)
Access Control	Only System Admin and authorized auditors can access raw logs
Search	Full-text search and filtering by any field
Real-time	Logs available for search within 60 seconds of event

Why Tamper-Evident Matters

If an attacker compromises the system, they might try to delete or modify logs to cover their tracks. WORM storage prevents this: once a log entry is written, it cannot be modified or deleted until the retention period expires. This is a SOC 2 requirement and a critical forensic capability.

Enterprise Admin Audit UI

Enterprise admins (the client's internal administrators) need self-service access to audit logs for their own organization. The Audit UI provides:

• Search and filter by date range, user, event type, resource
• Export to CSV/JSON for offline analysis
• Pre-built reports: failed login attempts, data access by user, admin actions
• Alerting: configure alerts for specific event patterns (e.g., unusual data access)
• Compliance views: SOC 2 evidence packages, access review reports

Scope Limitation

Enterprise admins can ONLY see audit logs for their own tenant. Cross-tenant log access is impossible -- this is enforced at the database query level and verified by the authorization middleware.

Mobile and Offline Considerations

When users access the platform from mobile devices, especially in offline mode:

• Offline actions are queued locally and logged when the device reconnects
• Offline audit events include both the action timestamp and the sync timestamp
• Device ID is included in mobile audit events for forensic correlation
• Local cache access events are logged when the device is online
• Mobile session events (app backgrounded, foregrounded, terminated) are tracked

Internal Access Monitoring

For ReGenesis employees with system access:

Control	Description
Break-glass access	Emergency production access requires approval and is fully logged
Just-In-Time (JIT)	Access granted temporarily (max 4 hours) with automatic revocation
Access justification	Every internal access request must include a reason
Quarterly access reviews	All internal access reviewed and recertified quarterly
Anomaly detection	Unusual access patterns trigger alerts to Security Officer

Technical Spec