Access Control Policy

1. Purpose

This policy sets the rules that decide who may see, change or use the Organisation's information, systems, networks and premises, and under what conditions. Its aim is that every person and every system process gets the access needed for a defined business purpose, nothing more, for no longer than needed, and that each grant can be traced to an approval and each use can be traced to an identity.

The detailed steps are in the User Access Management Procedure. This policy states the rules those steps must satisfy and gives a short summary of the access lifecycle so that managers can see the whole picture in one place.

2. Scope

The policy applies to every user identity, human or non-human, that can reach information assets owned or held by the Organisation, wherever those assets sit.

• In scope: employees, contractors, consultants, interns, temporary staff, suppliers' staff and customers' staff who are given an account, badge, key, token or certificate.
• In scope: all information systems, applications, databases, operating systems, network devices, cloud services, code repositories, shared drives, collaboration tools and physical areas holding information.
• In scope: service accounts, application programming interface keys, shared mailboxes, test accounts and any other non-human identity.
• In scope: remote, on-site and cloud access, and access from personally owned devices that the Organisation permits.
• Out of scope: public web content intended for anyone to read and customer-facing sign-in rules for the Organisation's own products, which follow the product security requirements. Customer data inside those products stays in scope for staff access.

3. Terms and definitions

4. Roles and Responsibilities

4.1 Accountability notes

The system owner, not IT, is accountable for who has access to a business system. IT is responsible for carrying out approved changes correctly. Where a system has no named owner, the Head of IT Security acts as owner until one is appointed, and the gap is recorded as an issue in the asset register.

5. Access Control Policy Statements

5.1 Principles

• Access is granted on a need-to-know and least-privilege basis, tied to a role and a stated business purpose.
• Everything is denied unless it is explicitly allowed. Default accounts and default permissions are removed or disabled on installation.
• Every identity is unique to one person or process. Shared personal accounts are not permitted; where a shared function is unavoidable it uses a shared mailbox or a checked-out credential in a password vault with individual attribution.
• Duties are separated so that no single person can request, approve and implement a sensitive change or payment alone.
• Access follows the classification of the information as set in the Information Classification and Handling Policy: the higher the classification, the tighter the approval and review.
• Role-based access is the default. Roles are defined by system owners and reviewed at least [every 12 months]; individual exceptions to a role are approved and recorded.

5.2 Authentication

• Every account must authenticate before reaching any non-public resource.
• Passwords must be at least [14 characters], not on a list of known breached passwords, and unique to the Organisation. Forced periodic change is not required unless compromise is suspected; the password must change at once on suspicion of compromise.
• Multi-factor authentication is mandatory for remote access, for all administrator and privileged accounts, for email and collaboration tools, for code repositories and for any system holding [Confidential] or higher information.
• Accounts lock after [5] failed attempts and unlock only through a verified process or after [15 minutes].
• Credentials are stored only as salted hashes or in an approved password vault. They must never be sent in plain text, written down in an open place, or embedded in source code or documents.
• Session timeouts: idle screens lock after [10 minutes]; remote and administrative sessions end after [30 minutes] of inactivity.

5.3 Network and remote access

• Remote access to internal resources uses an approved secure channel with multi-factor authentication and a device that meets the Mobile Device and Teleworking Policy.
• Administrative interfaces are not exposed to the internet. They are reachable only from management networks or through a bastion or equivalent controlled path.
• Wireless networks for guests are separate from internal networks.

5.4 Third-party and customer access

• Suppliers and customers receive named accounts with the minimum scope, a sponsor inside the Organisation, and an end date no later than [12 months], renewable on request.
• Supplier access to production systems or customer data is granted only where the supplier agreement covers confidentiality and security obligations, as set out in the Supplier Relationship Management Policy.
• Supplier support sessions are enabled for the time needed and observed or recorded where the system holds [Confidential] data.

5.5 Source code and development environments

• Write access to production code branches is limited to approved maintainers and requires peer review before merge.
• Developers do not hold standing access to production data. Production access for fault finding is time-limited and approved as an emergency or privileged request.
• Secrets, keys and tokens live in a secrets management tool and are never committed to repositories.

5.6 Physical access

Physical access to offices, server rooms and storage is granted on the same least-privilege principle and is detailed in the Physical and Environmental Controls Policy. HR leaver notices trigger badge and key recovery in the same step as account removal.

6. User Access Lifecycle Summary

This section summarises how access is created, approved, recorded, logged, reviewed and removed. The numbered steps, forms and time targets are in the User Access Management Procedure. In any difference, the stricter rule applies until the owner of the document resolves it.

6.1 Creation of a user account

• An account is created only against a request recorded in [the ticketing tool], raised by the line manager or HR for a named person, naming the systems, role and business reason.
• The default for a new joiner is the standard access bundle for the role. Anything beyond the bundle needs the system owner's approval.
• The service desk creates the account within [1 working day] of full approval, sets a one-time initial credential delivered separately from the user name, and forces change at first sign-in.
• User names follow one naming convention, are never reused for another person, and do not reveal privilege level.
• Pre-employment screening under the HR Security Policy must be complete before access to [Confidential] systems is given.

6.2 Approval of access

Approval is proportionate to the sensitivity of what is being reached. The approver must be someone other than the requester, and the person who implements the change must not be the sole approver.

6.3 Change of role and deletion of access

• When a person moves role, the line manager raises a change request within [2 working days]. Access from the previous role is removed unless the new role needs it and the system owner confirms.
• On exit, HR notifies the service desk before the last working day. Accounts are disabled at the agreed exit time, and no later than [end of the last working day], with immediate disablement for dismissal or any security concern.
• Mailboxes and files are handed to the line manager as directed. Accounts are deleted after [90 days], unless a legal hold or investigation applies. Tokens, keys, badges, devices and vault entries known to that person are revoked or rotated the same day.
• Dormant accounts with no sign-in for [60 days] are disabled and those inactive for [180 days] are removed after owner confirmation.

6.4 Recording of user IDs

• A register of all accounts, whether kept in the directory, the identity tool or another source, records for each: unique ID, person or process, employer or sponsor, system, role, approver, start date, expiry date and status.
• The register is reconciled with HR and supplier lists at least [monthly] and any orphan account is investigated within [5 working days].
• Service accounts have a named human owner, a stated purpose, a rotation schedule for the secret and a record of every system they can reach.

6.5 Logging of access

• Successful and failed sign-ins, privilege use, account changes, access to sensitive data stores and changes to permissions are logged on every in-scope system.
• Logs are protected from alteration, synchronised to a common time source and kept for at least [12 months], and for ICT logs the period required by the CERT-In Directions of 28 April 2022 (180 days, held within Indian jurisdiction) [confirm the current requirement].
• Alerts are defined for repeated failures, sign-ins from unusual places or at unusual times, creation of privileged accounts and use of break-glass accounts. Detail is in the Logging and Monitoring Policy.

6.6 Privileged user IDs

• Administrators use a separate privileged account for administrative work and an ordinary account for email, browsing and documents. A privileged account is never used for daily tasks.
• Privileged access is time-bound, approved per task or per period of no more than [90 days], and re-approved on expiry.
• Where tooling permits, privileged access is obtained just in time, through a vault or privileged access tool that records the session.
• Break-glass accounts are kept sealed, tested at least [every 6 months], monitored for any use, and the password is changed after each use. Every use is reviewed by the Head of IT Security within [1 working day].
• The list of privileged accounts is reported to the Head of IT Security [monthly] and reviewed in full [every 3 months].

7. Access Requirements by Classification

The strength of control rises with the classification of the information reached. The table gives the minimum for each level; system owners may require more. Levels are defined in the Information Classification and Handling Policy.

8. Service Accounts and Machine Access

• Service accounts and application keys are created only through a request that names the owner, purpose and systems reached, and are never used by a person to sign in interactively.
• Secrets are held in a secrets management tool, not in code, scripts, tickets or chat messages, and are rotated at least [every 12 months] or at once when the owner leaves or compromise is suspected.
• Each key or service account carries the minimum permission for its task and is scoped to the environment (development, test or production) it serves. Production credentials are never used in other environments.
• Automated jobs that need production access run through the change process, and any change to their permissions follows the Change Management Policy and Procedure.

9. Emergency and Temporary Access

Emergency access may be given by the on-call manager when a service outage or a security incident cannot be handled without it. The grant is recorded at the time with the incident or change reference, expires automatically within [24 hours], and is ratified or reversed by the system owner on the next working day. Temporary access for projects, audits or investigations is limited to the dates stated in the request. Accounts without an expiry date are not permitted for external persons.

10. Handling Joiners, Movers and Leavers

The timeline below sets the maximum time between the trigger and the access action. HR is the authoritative source for starts, role moves and exits.

11. Access Review and Recertification

System owners confirm that access is still needed on the schedule below. Reviewers receive a list showing user, role, last sign-in and approval date. Access not confirmed within [10 working days] of the request is suspended until confirmed. Removals identified in a review are done within [2 working days].

12. Segregation of Duties

Access must not let one person complete a risky sequence alone. System owners identify conflicting combinations for their systems and the Head of IT Security keeps the combined list. Where separation is impossible, for example in a small team, a compensating control such as independent review of logs or transactions is recorded and applied.

13. Detection of Improper Access

Prevention is backed up by detection. Security operations maintain the alerts below, tune them at least [every 6 months], and investigate each alert within the target time.

14. Compliance and monitoring

The Head of IT Security checks adherence through the access review results, reconciliation of the account register with HR records, sampling of requests for complete approval evidence and log-based detection of improper use. Results are reported at least [quarterly] to top management and are an input to internal audit.

15. Records and evidence

The following records are kept in [the document management system] and the ticketing tool for [3 years] unless the records schedule says otherwise:

• Access requests with approvals, implementation and completion timestamps.
• The account and privileged account registers, with monthly reconciliation outputs.
• Access review sheets with removals and sign-off.
• Break-glass use records, and supplier access and expiry records.
• Exception approvals and the exceptions register.
• Access logs for the period given in the Logging and Monitoring Policy.

Annexure A: Access request form

16. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

17. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

18. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• User Access Management Procedure
• HR Security Policy
• Acceptable Usage Policy
• Logging and Monitoring Policy
• Information Classification and Handling Policy
• Supplier Relationship Management Policy
• Mobile Device and Teleworking Policy