Access Management —
who can access what,
and nothing more.

What this policy governs

This Access Management Policy establishes the requirements for managing access to the VIGIL platform, its underlying infrastructure, its data, and all associated internal systems operated by Anshin Risk and Resilience Consulting Private Limited (ARRC Global). It applies to:

• All platform user access — including client organisation administrators, analysts, and viewer-role users
• All ARRC Global internal access — developers, operations personnel, and any individual with access to production systems or client data
• All infrastructure access — servers, databases, network components, and cloud or hosting provider consoles
• All service and machine access — API keys, service accounts, deployment pipelines, and automated processes
• All third-party access — contractors, consultants, auditors, and any external party granted access to any VIGIL system

Compliance with this policy is mandatory. Access granted in violation of this policy is considered unauthorised access regardless of the intent of the individual holding it.

The rules that shape every access decision

• Least privilege. Every user, service, and system is granted the minimum level of access required to perform its specific function. Access is not granted based on seniority, convenience, or anticipated future need.
• Need to know. Access to data is granted only where there is a documented operational need to access that specific data. Broad read access to all data "for reference" is not a valid justification.
• Zero trust. No access request is implicitly trusted based on network location, device, or prior authentication. Every access request is authenticated and authorised independently, regardless of origin.
• Default deny. Access is denied by default. It must be explicitly granted. Undocumented or unconfigured access states are treated as denied, not permitted.
• Separation of duties. No individual holds access rights that allow them to both initiate and approve a sensitive operation without a second authorised party. Critical functions require at least two independent actors.
• Time-bound access. Elevated or temporary access is granted for the minimum time required. Access that was appropriate for a specific task is revoked when that task is complete — not when it is convenient to revoke it.
• Access is auditable. Every grant of access, every use of access, and every revocation of access is logged and available for audit. Access that cannot be audited is not granted.

The distinct access environments governed by this policy

Platform Access — Client Users

Access by individuals authorised by a client organisation to use the VIGIL platform. Client user access is managed through the platform's built-in RBAC system. Client organisation administrators manage user provisioning within their account. ARRC Global manages the role framework and the platform controls that enforce it.

Platform Access — ARRC Global Internal

Access by ARRC Global personnel to the VIGIL platform for operational, development, support, or administrative purposes. Internal access to production platform data is restricted to the minimum personnel necessary for the specific operational function and is subject to the privileged access controls in Section 7.

Infrastructure Access

Access to the servers, databases, network components, and hosting provider management consoles that underpin the VIGIL platform. Infrastructure access is the highest-sensitivity access category. It is restricted to named ARRC Global personnel with a specific operational need, requires MFA without exception, and is logged comprehensively.

Source Code & CI/CD Access

Access to the VIGIL source code repository and deployment pipeline. Access is restricted to active developers with a current need. Read access and write access are separately controlled. Pipeline configuration access — which controls what is deployed to production — is the most restricted access within this category.

Service & Machine Access

Access by automated systems, services, and deployment pipelines using API keys, service account credentials, or machine tokens. Service accounts operate under the same least-privilege requirement as human accounts. Service account credentials are rotated on a defined schedule and immediately upon any suspected exposure.

The VIGIL platform RBAC framework

The VIGIL platform implements Role-Based Access Control (RBAC) for all user access. Roles define the permissions available to a user — permissions are not assigned individually. Every platform user is assigned exactly one role within their client organisation's account.

Grant, maintain, review, revoke

Request & Approval

• All access requests must document: the specific access required, the business purpose, the expected duration, and the requesting individual's identity.
• Platform user access for client organisations: requested and approved by the client's Org Admin within the platform. No ARRC Global approval is required for standard client user roles.
• ARRC Global internal access to production systems: requested by the individual and approved by the Founding Principal. No self-provisioning of production access.
• Temporary elevated access: approved for a specific task and a defined time period. Time-bound access requests include an explicit expiry date.

Provisioning

• Access is provisioned to the exact scope approved — not to the broadest available role that covers the need.
• New accounts are provisioned with credentials communicated through a secure channel. Initial credentials require change on first login.
• Provisioning is logged with: the account created, the role assigned, the approver, and the date.

Active Use & Monitoring

• All authentication events, authorisation decisions, and data access events are logged to the central logging system.
• Anomalous access patterns — unusual hours, unusual data volumes, access from new locations, repeated failed attempts — generate alerts for review.
• Dormant accounts — accounts with no activity for 60 days — are flagged for review and suspended pending confirmation of continued need.

Periodic Review

• All ARRC Global internal access rights are reviewed quarterly. Reviews confirm that each access grant remains appropriate for the individual's current role and responsibilities.
• Client platform accounts are subject to review by the client's Org Admin — ARRC Global does not manage client user access on the client's behalf, but provides activity data to support the client's own access reviews on request.
• Service account access rights are reviewed quarterly alongside human account reviews.
• Review outcomes are documented. Access that cannot be confirmed as currently necessary is suspended pending clarification, not retained as a default.

Revocation

• Immediate revocation triggers: confirmed or suspected account compromise; departure of a personnel member; end of a contractor engagement; client subscription termination; security incident requiring access isolation.
• Revocation on personnel departure is completed within 2 hours of the departure being confirmed — not at the end of the working day, not at the next convenient time.
• Revocation covers all access: platform accounts, infrastructure access, source code repository access, service account credentials, and any physical or logical access associated with the individual.
• Revocation is logged with: the account revoked, the reason, the individual who performed the revocation, and the timestamp.
• Client-side revocation: client organisations are responsible for revoking their own users' platform access. ARRC Global provides immediate account suspension capability to Org Admins and will forcibly suspend any account at a client's written request.

How identity is verified at every access point

Multi-Factor Authentication

• MFA is mandatory for all ARRC Global internal accounts — including platform access, infrastructure access, source code repository access, and any internal tooling with access to production data or systems. No exceptions.
• MFA is available to all platform users and strongly recommended. Client organisations may enforce MFA for their users through platform settings — ARRC Global recommends all enterprise clients enable this setting.
• Accepted MFA methods: TOTP authenticator applications (Google Authenticator, Authy, and equivalents). SMS-based OTP is not accepted as a primary MFA method for internal accounts due to SIM-swap vulnerability.

Password Standards

• Minimum length: 12 characters for standard accounts; 16 characters for privileged accounts
• Complexity: mix of uppercase, lowercase, numeric, and special characters
• Breach checking: passwords are checked against known compromised credential databases at account creation and password change
• No reuse of the previous 10 passwords
• Maximum password age: 12 months for standard accounts; 90 days for privileged accounts
• Password managers are encouraged for all personnel — storing passwords in plaintext documents, spreadsheets, or communication tools is prohibited

Session Management

• Platform sessions expire after 15 minutes of inactivity for standard users; 10 minutes for privileged sessions
• Absolute session maximum: 8 hours — re-authentication required after this period regardless of activity
• Concurrent sessions from different geographic locations generate a security alert and require re-verification
• Session tokens are invalidated immediately on logout and cannot be reused

Account Lockout

• 5 consecutive failed authentication attempts trigger a temporary lockout
• Lockout duration: 15 minutes for the first lockout; doubling for each subsequent lockout within a 24-hour period
• Lockout events are logged and anomalous patterns (multiple accounts locked simultaneously, lockouts from a single IP) generate security alerts
• Account unlock for internal ARRC Global accounts requires authorisation from the Founding Principal — self-service unlock is not available for internal accounts

The highest-sensitivity access category

Privileged access — meaning access to production infrastructure, databases, or any system that provides direct access to client data outside the application layer — is the most sensitive access type in VIGIL's environment. It is subject to the highest controls.

• Named individuals only. Privileged access is granted to named individuals, not to roles or teams. Every privileged access grant identifies a specific person and a specific system or scope.
• Minimum number of privileged accounts. The total number of individuals with privileged access to any production system is the absolute minimum required for operational continuity. Privileged accounts are not granted for convenience or as a precaution.
• MFA without exception. MFA is mandatory for all privileged access. No privileged access session is authenticated without a valid second factor.
• Just-in-time access where feasible. Where infrastructure tooling supports it, privileged access is granted just-in-time for a specific session and revoked automatically at session end — rather than maintained as a standing permission.
• No shared privileged accounts. Shared credentials for privileged access are prohibited. Every privileged session is attributable to a specific named individual.
• Full session logging. All privileged access sessions are logged at the command or action level, not only at the authentication event level. Logs are stored in a location that the privileged user cannot access or modify.
• Privileged access to client data. Any ARRC Global personnel access to client data within the platform — outside the normal application interface — is treated as privileged access. It is logged at the record level, requires approval from the Founding Principal, and is conducted only when operationally necessary (e.g. support investigation with client consent). ARRC Global personnel do not access client data for any other purpose.
• 90-day review. Privileged access grants are reviewed every 90 days. Any grant that cannot be confirmed as currently operationally necessary is revoked.

Contractors, auditors, and external parties

• Access only when necessary. Third-party access to any VIGIL system is granted only when operationally unavoidable and for the minimum scope and duration required.
• Confidentiality agreement first. No third party is granted access to any VIGIL system before executing an appropriate confidentiality or non-disclosure agreement. The agreement must specifically cover the systems and data the third party will access.
• Named individuals, not organisations. Third-party access grants name the specific individuals authorised — not the organisation they represent. If the third-party organisation changes the personnel assigned, the access grant must be updated before the new individual accesses any system.
• Supervised access preferred. Where possible, third-party access to sensitive systems is conducted under supervision by an ARRC Global team member. Unsupervised access requires explicit approval from the Founding Principal.
• Dedicated credentials. Third parties receive dedicated credentials — never shared credentials used by ARRC Global personnel. Third-party credentials are distinct, traceable, and revocable independently.
• Time-limited access. Third-party access is granted for the duration of the specific engagement only. Access is revoked at engagement end — not when the third party requests revocation, not at the next convenient review cycle.
• Access audit on engagement end. When a third-party engagement concludes, access is revoked and a review is conducted to confirm all credentials, keys, and access paths used by the third party have been invalidated.

Keeping access current and accountable

• Quarterly internal review. All ARRC Global internal access rights — platform, infrastructure, source code, and service accounts — are reviewed quarterly. The review confirms that each access grant is current, appropriately scoped, and documented. Access that fails review is suspended immediately pending clarification.
• Access register. A current access register is maintained documenting all ARRC Global internal access grants: the individual or service, the system or scope, the role or permission level, the approver, the date granted, and the date of last review. The register is updated within 24 hours of any access change.
• Privileged access review. Privileged access grants are reviewed every 90 days — more frequently than the standard quarterly cycle, reflecting their higher risk.
• Dormant account action. Accounts with no activity for 60 consecutive days are suspended automatically. Reactivation requires re-approval following the same process as a new access request.
• Audit log retention. All access logs — authentication events, authorisation decisions, data access records, and privileged session logs — are retained for 12 months in the central logging system and available for audit on request.
• Client access audit support. Enterprise clients may request an access audit report confirming which ARRC Global personnel have accessed data within their account, and when, for any period within the log retention window. This is provided at no charge within 10 business days of request.

What is never permitted

• Sharing credentials. Sharing login credentials — including passwords, MFA codes, session tokens, API keys, or any other authentication material — with any other individual, regardless of their role or relationship, is strictly prohibited.
• Generic or shared accounts. Shared accounts with no individual attribution are prohibited. Every account must be attributable to a specific named individual or named service.
• Hardcoded credentials. Embedding credentials, API keys, passwords, or authentication tokens in source code, configuration files, documentation, scripts, or any other stored artefact is prohibited. See the Secrets Management section of the Secure Development Policy.
• Bypassing access controls. Attempting to access systems, data, or functions beyond what has been explicitly granted — including through technical means, social engineering, or exploitation of misconfiguration — is a serious policy violation treated as a security incident.
• Retaining access after need expires. Retaining access to a system or data after the purpose for which it was granted has ended — without explicit renewal approval — is a policy violation. Personnel are responsible for notifying the Founding Principal when access they hold is no longer needed.
• Access from unsecured endpoints. Accessing production systems or client data from devices that are not subject to endpoint protection, current OS patching, and full-disk encryption is prohibited.
• Unlogged access paths. Creating or using access paths to production systems or data that bypass the central logging system is prohibited, regardless of technical feasibility.

Accountability across the access management function

• Founding Principal. Policy owner. Approves all ARRC Global internal access grants to production systems. Approves all privileged access grants. Reviews the access register quarterly. Accountable for compliance with this policy across the organisation.
• All ARRC Global personnel. Responsible for: using only the access they have been explicitly granted; protecting their credentials; reporting suspected credential compromise or unauthorised access immediately; notifying the Founding Principal when access they hold is no longer operationally required.
• Client Org Admins. Responsible for managing access within their client organisation's platform account — provisioning users, assigning roles, reviewing access, and revoking access when users leave or change roles. ARRC Global provides the controls; the Org Admin operates them.
• Development and operations team. Responsible for: implementing and maintaining the technical access controls described in this policy; logging access events as specified; alerting on anomalous access patterns; and ensuring revocation mechanisms function correctly and promptly.

Policy maintenance and document access

This policy is reviewed annually and updated following any access-related security incident, significant change to the platform's access architecture, or material change to the organisation's personnel or operational structure. The quarterly access review cycle is independent of the annual policy review.

Enterprise clients and procurement teams requiring the full Access Management Policy — including the access register template, review procedures, and RBAC implementation documentation — may request it below.