Identity & Access Management (IAM) Policy

Purpose

This policy defines how Vaxa Analytics manages identities and access to systems, applications, and data. It ensures access is granted based on business needs while minimising security risks. The policy aligns with our Zero Trust Network Architecture (ZTNA) principles, ensuring access is continuously verified, minimises privileges, and follows least privilege access principles.

Scope

This policy applies to all employees, contractors, vendors, and third parties who access Vaxa’s IT systems, applications, or data.

Roles & Responsibilities

Policy Statements

Identity Verification & Authentication

• All access is identity-based and requires strong authentication.
• Multi-Factor Authentication (MFA) is mandatory for all accounts where technically feasible.
• Passwordless authentication methods should be used.
• Service accounts and machine identities must have unique credentials and not be used for interactive login.
• Break-glass accounts are tightly controlled, regularly audited, and credentials are long, unique, and unpredictable.

Zero Trust, Least Privilege Access, & Role-Based Access Control (RBAC)

• Access is denied by default and granted on a need-to-know, least privilege basis.
• Users must request access through a formal approval process.
• Privileged access must be reviewed regularly and revoked if no longer required.
• Access must be continuously monitored, logged, and revoked in case of suspicious activity.
• Access to systems and data is role-based, ensuring least privilege access.
• RBAC must be implemented in all critical systems, assigning users permissions based on job functions.
• Access to applications is managed via security groups, rather than assigning permissions at an individual level.
• System Owners define and manage RBAC roles and group memberships, subject to Information Security Group (if typical) or CTO approval (if subject to an Evaluation of Privilege Requests Procedure).

Identity Lifecycle & Access Reviews

• Access must be provisioned and deprovisioned as part of the onboarding and offboarding process.
• Automatic deactivation of privileged accounts should occur:
  • After 12 months unless revalidated.
  • After 45 days of inactivity.
  • And, should occur as soon the access is no longer required.
• Access reviews:
  • System Owners conduct quarterly reviews of privileged access.
  • User access to business-critical systems is reviewed every 6 months.
  • Terminated employees must have access revoked immediately.

Monitoring & Auditing

• All privileged access events are logged, stored centrally, and protected from unauthorised modification or deletion.
• All privileged account and group management events are logged, stored centrally, and protected.
• Logs are monitored for unusual activity, with alerts raised for suspicious access attempts.
• Break-glass accounts are tightly controlled, regularly audited, and credentials are long, unique, and unpredictable.

Exceptions

Any exceptions to this policy require documented approval from the CTO and Information Security Group. Exceptions must be risk-assessed and periodically reviewed.

Compliance & Monitoring

• Information Security Group will conduct regular audits to ensure compliance.
• IAM policies will be reviewed annually to ensure they remain effective.
• Violations of this policy may result in disciplinary action, up to and including termination.

References

• Information Security Policy
• Privileged Access Policy