User Access Control Policy

Document Control

Revision history

1. Introduction and Scope

This policy provides the framework for how user accounts and privileges are created, managed, reviewed and removed across Hamurlabs. It defines how new users are authorised and granted appropriate privileges, how those privileges are reviewed and revoked, and the controls that prevent users from obtaining unauthorised access.

This policy applies to all employees, contractors and suppliers who have access to Hamurlabs information and information systems, and to all systems used by Hamurlabs, including: the HaROS production and non-production environments, Google Cloud projects, source code repositories, CI/CD tooling, corporate SaaS applications (email, document collaboration, communication, support/ITSM), and databases. Certain roles — in particular privileged and production access — require stronger controls than those applied to standard users.

2. Definitions

3. Policy Statements

3.1 Principle of Least Privilege

Access must be allocated on the basis of business need and least privilege. Users must be provided only with the minimum access rights and permissions to systems, services, information and resources that they need to fulfil their role. Access to customer data in production is restricted to personnel whose role requires it and is granted per the controls in Section 3.5.

3.2 Account Lifecycle (Joiner – Mover – Leaver)

• Joiner: accounts are created only upon a documented request approved by the Access Approver. Default access for a role may be defined in a role-based access matrix maintained by the ISM.
• Mover: when a user changes role or business need changes, access rights must be adjusted promptly; rights no longer required must be revoked, not accumulated.
• Leaver: all access of departing personnel must be revoked no later than the last day of employment or engagement (same day for third parties), and any access tokens or hardware must be recovered. Account deactivation takes priority over data handover arrangements.
• All additions, deletions, suspensions and modifications of access must be captured in an audit trail showing who took the action and when.
• Accounts not accessed for 90 days without prior arrangement must be disabled.
• Account management procedures may be executed only by suitably trained and authorised personnel.

3.3 Authentication

• All access to Hamurlabs information systems must be controlled by an approved authentication method that verifies the user’s identity — as a minimum, a unique user ID and strong password.
• Single sign-on through the corporate identity provider must be used wherever the system supports it.
• Multi-factor authentication (MFA) is mandatory for: the identity provider, email, Google Cloud, source code repositories, remote access, and all administrative interfaces.
• Each user ID must be unique and must never be reused or duplicated. Users are normally limited to one account per system for non-administrative purposes; variations require ISM approval.

3.4 Password Management

• Passwords must not be shared with any other person for any reason.
• All default system and vendor passwords must be changed immediately upon installation.
• Systems must support strong password management (length, complexity or passphrase support, history, account lockout). Minimum password length is 12 characters; the use of the corporate password manager is required for shared secrets and strongly recommended for individual credentials.
• New accounts must be forced to change their initial password at first use; passwords must be changed on indication or suspicion of compromise.
• Secrets used by systems (API keys, tokens, service-account keys) must be stored in an approved secrets manager, never in source code, tickets or chat.

3.5 Privileged and Production Access

• All privileged accounts must be based on job function and authorised by the ISM (or the executive responsible for technology) before access is granted.
• Privileged actions must be performed from individual accounts; use of shared root/administrator credentials is prohibited except in documented break-glass procedures.
• All changes to privileged accounts must be logged and reviewed regularly.
• Access to production customer data must be limited to named personnel, logged, and reviewed quarterly.
• Privileged access rights are reviewed quarterly; standard access rights are reviewed at least annually. Reviews are coordinated by the ISM with each manager.

3.6 Monitoring

Systems must be capable of logging events relevant to potential security breaches, and user access is subject to management checks. Anomalies identified in access rights — excessive, unused or inconsistent permissions — must be challenged and corrected.

4. Responsibilities

5. Compliance

Compliance with this policy is assessed regularly by the ISM through access reviews and audits. Any violation must be investigated and may result in disciplinary action in accordance with the Information Security Policy.