Access Control Policy

1. Purpose and scope

This policy governs how access to the CDR data environment is granted, controlled, reviewed, and removed. The environment is the manageyourtax-prod Google Cloud project (Cloud Run, Firestore, Cloud Storage; australia-southeast1), the source repository and CI/CD, the Google Cloud console, and Google Secret Manager. It applies to all human and service accounts.

2. Principles

Access is granted on the principles of least privilege and need to know, with role-based access and segregation of duties so far as the team size allows. Where full segregation is not achievable, compensating controls (logging, review, and independent assessment) are applied and the limitation is documented.

3. Identity and authentication

• Multi-factor authentication is required for access to production systems and the cloud console, for every user. Org-wide MFA enforcement in Google Workspace is being rolled out.
• End-user authentication routes through the AndGo platform identity service (OAuth 2.0 → Firebase Auth). Administrative/console access uses individual Google accounts.
• Password controls follow Google/Firebase enforced standards (complexity, lockout, history); shared knowledge of passwords is prohibited.

4. Authorisation and roles

• Application roles are owner, admin, standard and read_only; access rights are limited to what each role requires.
• Administrative privilege in Google Cloud is granted only as needed, to named individuals, for the period required, and is not self-grantable. Application "admin" is governed by a controlled email allowlist, not a self-service role.
• Every server API route enforces authorisation server-side (requireBusinessAccess: verifies the Firebase ID token and cross-checks business ownership/membership). Firestore Security Rules are deny-by-default and enforce per-business isolation.

5. Unique IDs and service accounts

• Each human user has a unique identity; generic/shared logins are prohibited.
• Service accounts (e.g. the Cloud Run runtime identity) are limited to the minimum IAM roles required (e.g. secretAccessor for the federation secret). Service-account actions are captured in Cloud Audit Logs.

6. Provisioning, review, and revocation

• Provisioning: access is requested against a defined role, approved by the Compliance/Technical Lead, and granted only after HR Security screening, training, and Acceptable Use acknowledgement are complete.
• Review: user access and privileges are reviewed at least quarterly; findings and any changes are recorded.
• Revocation: access is revoked promptly on role change or departure (target: same business day) and the action is recorded.

7. Logging and monitoring

Critical events — authentication, administrative actions, and CDR-data access — are logged to Google Cloud Logging and the immutable application audit trail (server-stamped, append-only, Admin-SDK-only writes, with an owner-only viewer). Logs are retained and reviewed for irregularities; retention meets CDR requirements.

8. Physical access

CDR data is hosted in Google Cloud Australian data centres under Google's physical-security controls. Physical access to NTDG premises and to any device that can access the CDR environment is restricted to authorised personnel.

9. Encryption in transit

All access to the environment is over TLS 1.2+ with HSTS; internal Google Cloud traffic is encrypted. See the Security Policy for the full encryption position.

10. Records

Access requests, approvals, reviews, and revocations are retained for at least six years.

Contact