Assenture

Logging and Monitoring Policy

Last updated: August 8, 2026

This policy defines how Assenture generates, protects, retains, monitors and acts upon logs for all production assets. It applies to all production and pre-production environments, all Assenture personnel and contractors, and to any subprocessor operating on our behalf. It is read together with our Security Policy, Access Controls Policy, Data Retention and Disposal Policy and Privacy Policy.

1. Objectives

  • Maintain a complete, attributable and tamper-evident audit trail of material events in production.
  • Detect, alert on and triage security-relevant events in near real time.
  • Support incident response, forensic reconstruction, customer enquiries and regulatory obligations.
  • Detect potential data exfiltration and unauthorised access to consumer financial data.
  • Retain logs long enough to be useful, and no longer than necessary.

2. What is logged

Every material event in a production asset is logged. Material events include, at minimum:

  • Authentication. Sign-in success and failure, multi-factor enrolment, factor removal, step-up challenges, passkey registration, password reset, session revocation and sign-out.
  • Authorisation and privilege. Role creation and edits, permission grants and revocations, workspace membership changes, ownership transfer and every attempted-but-denied privileged action. These are captured by database triggers, so they cannot be bypassed by calling the API directly.
  • Data access and mutation. Create, update and delete operations on customer records, financial transactions, payroll, employee records and documents, with actor identity, workspace, timestamp and source.
  • Financial connectivity. Bank account link, re-link, sync, token refresh and disconnect events for our aggregation partner, including the initiating user and whether the session was elevated to a second factor.
  • Administrative and infrastructure actions. Deployments, configuration and schema migrations, secret rotation, feature-flag changes, and staff access to production consoles.
  • Application and platform telemetry. Server function invocations, error traces, rate-limit and abuse triggers, edge/WAF decisions, and database query anomalies.
  • AI and automation. Agent invocations, the acting user's identity, the tools called and any consequential action taken on the user's behalf.

3. Log record contents

Each record captures, where applicable: event type and outcome, UTC timestamp, actor identity (user, service or agent, never a shared account), workspace or tenant, target object and its identifier, before and after values for privilege changes, source IP address, user agent, request identifier and session/authentication assurance level.

Logs are treated as sensitive. Credentials, access and refresh tokens, API keys, full financial account numbers, and document contents are never written to logs; sensitive identifiers are redacted or truncated at the point of emission.

4. Integrity and access

  • Audit records are append-only. Application roles have no rights to update or delete audit rows; deletion is restricted to automated retention jobs running with a privileged service identity.
  • Logs are shipped off-host to a separate, access-controlled store so that compromise of a single asset does not permit log destruction.
  • Access to raw production logs is restricted to on-call engineering and security staff under least privilege, through SSO with phishing-resistant multi-factor authentication, and is itself logged.
  • Logs are encrypted in transit (TLS 1.3) and at rest (AES-256).
  • Time is synchronised via NTP across all assets so events can be correlated reliably.

5. Customer-visible audit trail

Workspace administrators have an in-product audit log covering security-sensitive activity in their workspace, including role and permission changes, membership changes, access to restricted modules, and financial connection events. Entries show who acted, what changed, and when. The customer-visible trail is a filtered view of the same authoritative records; customers cannot edit or delete it.

6. Retention

  • Security and privilege audit records: retained for 12 months in hot storage and archived for a total of 24 months.
  • Authentication and financial connectivity events: 24 months.
  • Application, infrastructure and access logs: 90 days hot, 12 months archived.
  • Records under legal hold or relevant to an open incident are retained until the hold or investigation is closed.

Expiry is enforced by automated jobs; disposal follows our Data Retention and Disposal Policy.

7. Monitoring, detection and alerting

Logs and metrics are continuously evaluated against detection rules and thresholds. Alerts route to an on-call rotation reachable 24/7 by paging, with automatic escalation if unacknowledged.

  • Availability and integrity. Uptime, error rate, latency, saturation and failed background jobs, with anomaly detection against baselines.
  • Authentication abuse. Credential stuffing patterns, impossible travel, repeated failed multi-factor challenges, and bursts of password resets.
  • Privilege anomalies. Owner-level grants, unusual role changes, and any denied privileged action, alerted in real time.
  • Financial data access. Unusual volume or velocity of access to bank connection data, or access without an elevated session.
  • Edge protection. WAF, bot management, DDoS and rate-limit signals from our edge provider feed the same alerting pipeline.
  • Dependency and platform health. Automated dependency vulnerability scanning and database security linting run continuously; new high-severity findings raise alerts.

8. Threat intelligence

We maintain awareness of evolving threats and countermeasures and route that intelligence to the engineers who can act on it. Sources include vendor and platform security advisories from our infrastructure, database, authentication and financial-aggregation providers; CVE and ecosystem advisory feeds wired into automated dependency scanning with pull-request alerts; national CERT and industry bulletins; and breach-corpus data used to reject compromised passwords at registration and change time. Advisories rated high or critical are triaged within one business day, and emergency patches are deployed out of band.

9. Data loss prevention

Controls are in place to monitor and alert on potential data exfiltration:

  • Egress and volume monitoring on data-access paths, with alerting on abnormal export, download or bulk-read activity by a single identity.
  • Export and bulk-download actions are logged as material events with actor, scope and record counts, and are rate-limited.
  • Row level security in the database constrains every query to the caller's tenant, so a compromised application path cannot enumerate other customers' data.
  • Secret scanning in source control and CI blocks credentials from being committed; alerts trigger immediate rotation.
  • Managed corporate devices enforce disk encryption, screen lock, patching and endpoint protection with alerting on unmanaged data movement.
  • Outbound sharing of production data outside approved systems is prohibited and monitored.

10. Triage and response

  1. Detect. An alert is raised automatically or reported by a person.
  2. Acknowledge. On-call acknowledges within 15 minutes for critical alerts.
  3. Classify. Severity 1 to 4 based on confidentiality, integrity, availability and regulatory impact.
  4. Contain. Revoke sessions, keys or access; isolate the affected asset; roll back or disable the offending path.
  5. Eradicate and recover. Patch, restore from verified backup where required, and confirm the trail is intact.
  6. Notify. Affected customers are notified without undue delay, and within 72 hours where a personal data breach is confirmed, together with any regulator or partner notification obligations, including notification to our financial data aggregation partner where consumer data obtained through it is implicated.
  7. Review. A blameless post-incident review produces corrective actions with owners and dates, and new or tuned detection rules.

11. Review and assurance

  • Alert coverage and noise are reviewed monthly; detection rules are tuned as the product changes.
  • Privileged access and audit trail completeness are reviewed quarterly.
  • This policy is reviewed at least annually, and after any significant incident or architectural change.
  • Logging is a release requirement: new features that touch customer, financial or permission data must emit audit events before they can ship.

12. Contact

Security questions, log or audit-trail requests and vulnerability reports: security@assenture.app.