Information Security Policy

1. Introduction and Policy Statement

This policy sets out how the Organisation protects the information entrusted to it by customers, employees, partners and regulators, and how it runs its Information Security Management System (ISMS). It is the top document of the library: every other policy, procedure, plan and register in the library takes its authority from it.

1.1 Statement from top management

Customers choose the Organisation because they trust it with their systems, their data and, often, their own customers. That trust is earned by consistent practice, and it can be lost by a single avoidable failure. Top management therefore treats information security as a condition of doing business, resourced and measured like any other critical function, and not as a technical side issue.

Top management commits to provide the people, budget and authority the ISMS needs, to set objectives that are reviewed at least [quarterly], to act on audit and incident findings, and to follow the rules it sets for everyone else. Every person who works for or with the Organisation is expected to understand this policy, to follow it and to report anything that puts information at risk. Approved by [the Chief Executive Officer] on behalf of top management.

1.2 Information security policy statement

The Organisation will protect the confidentiality, integrity and availability of the information it holds and the systems that process it, in proportion to the risk. To do so it will:

• identify and assess information security risks using the Risk Management Policy, and treat them to a level top management has accepted in writing;
• apply the controls of Annex A of the international standard for information security management that its risk assessment shows are needed, and record the choice in the Statement of Applicability;
• meet its legal, regulatory and contractual obligations, and keep the register of those obligations current;
• make security a requirement in every project, supplier contract, system change and hiring decision;
• train people for their security duties and hold managers accountable for their teams;
• detect, respond to and learn from incidents, and keep critical services recoverable within agreed objectives;
• audit itself, review the ISMS at planned intervals and improve it continually.

1.3 Information security objectives

Top management sets measurable objectives that follow from this policy. Each objective has an owner, a measure and a target, and progress is reported to the information security steering committee. Targets below are defaults to be confirmed at the first management review.

2. Purpose and Scope

2.1 Purpose

This policy has four purposes. It states the Organisation's commitment to information security and the principles that guide every decision on it. It describes how the ISMS and the library of policies and procedures fit together. It gives, for each of the Annex A controls of the standard, a short statement of what the Organisation requires, who is accountable and how it is done. And it shows readers where the detail is found.

2.2 Scope

The policy applies to the ISMS as defined in the ISMS Manual: all information, in any form, that the Organisation creates, receives, stores, processes or transmits, and all assets used to do so, at every location and in every cloud or hosted service the Organisation uses.

• In scope: the Organisation's employees, directors, interns, contractors, consultants, temporary staff and the employees of suppliers who have access to its information or systems;
• In scope: customer-facing platforms, internal business systems, development and test environments, networks, endpoints, mobile devices, cloud services, premises and paper records;
• In scope: information that belongs to customers and is handled under contract, which is protected to the stricter of this policy and the contract;
• Out of scope: the internal management systems of suppliers and customers, which are addressed through contracts and assurance, and the personal information of staff that is held on personal devices and has no connection with work;
• Out of scope: any business unit or site that top management has excluded in the ISMS Manual, with the reason recorded there.

2.3 Who must comply

2.4 Terms and definitions

3. Information Security Framework

The framework has a simple logic. The ISMS Manual describes the system and its scope. This policy sets the rules and states the requirement for each control. A-series policies take one topic each and set the detailed rules. B-series procedures and processes say how those rules are carried out, in steps with owners and time targets. Plans, registers and forms are the working records. The risk assessment decides which controls are needed, and the Statement of Applicability records the decision.

3.1 Layers of documentation

Where documents conflict, the order of precedence is law and contract first, then this policy, then the A-series policies, then the B-series procedures, then local work instructions. A conflict found in practice is logged as a non-conformity and resolved by the document owner.

3.2 Topic map: policies and procedures

The table maps each topic to the exact titles of the documents that carry the detail. The control sections later in this policy name the same documents.

3.3 How the framework is kept consistent

• Each A-series policy names its matching B-series procedure, and each procedure names the policy it implements, so the pair is read together.
• Every control in this policy points to the library documents that carry its detail, and every document points back to the Annex A controls it supports.
• The ISMS manager keeps the master list of documents in [the document management system], with owner, version, review date and status for each, and checks it [monthly].
• A new topic receives its own policy only when the steering committee decides the topic is important enough to need separate rules, an owner and a compliance check.
• The Statement of Applicability is updated within [10 working days] of any change to the risk treatment plan or to the controls in use.

3.4 Selecting and justifying controls

Controls are selected through risk assessment, not by copying the list of the standard. Each Annex A control is considered against the risk treatment plan, legal and contractual duties, and good practice. A control is either applied, with a reference to where it is implemented, or excluded, with a written reason that top management has accepted. The Organisation adds controls of its own where the risk calls for it, such as those for AI use and product risk.

4. Information Security Domains

The Organisation groups its security work into four domains so that responsibility, measurement and investment can be discussed in the same terms across the business. Each domain draws on controls from more than one Annex A theme.

4.1 Governance

Governance makes information security a managed activity. It covers the policy set, the allocation of roles, the risk method, the legal register, supplier assurance, internal audit and management review. The steering committee watches this domain most closely, because a weakness here lets weaknesses in every other domain persist unnoticed.

• Outputs: approved policies, risk register, legal register, supplier register, audit programme.
• Test of effectiveness: every control has an owner, a check and recent evidence.

4.2 Protection

Protection keeps information safe while it is stored, used and moved. Controls here prevent unauthorised access and accidental loss: the right person, the right access, the right handling, on a securely configured and physically protected asset.

• Outputs: asset inventory, classification scheme, access rules, secure baselines, key inventory.
• Test of effectiveness: access reviews, baseline scans and handling audits find few exceptions.

4.3 Defence

Defence assumes some attacks will get through and aims to detect and stop them early. It relies on logs that are complete and trustworthy, monitoring that is watched, vulnerabilities that are fixed in time, and intelligence that is used rather than merely collected.

• Outputs: monitored log sources, detection rules, patch and vulnerability reports, threat summaries.
• Test of effectiveness: detection and containment times are measured and improving.

4.4 Resilience

Resilience keeps critical services running and recoverable. It covers backup, redundancy, continuity planning, disaster recovery and the response to incidents, and it is proved by testing, not by planning alone.

• Outputs: business impact analysis, recovery objectives, tested plans, incident records.
• Test of effectiveness: restore and failover tests meet the agreed objectives.

5. ISMS Management

The ISMS is led by top management, steered by a committee, run day to day by the ISMS team and carried out by every function. This section fixes who does what.

5.1 Top management

Top management is accountable for the ISMS. It approves this policy, sets objectives, assigns roles and authorities, makes resources available, takes part in the steering committee and management review, and decides what risk the Organisation will accept. It may delegate tasks but not accountability.

5.2 Information security steering committee

The committee turns top management's direction into decisions and watches performance. It is chaired by [the Chief Executive Officer or a delegate] and records decisions in minutes kept as ISMS records.

5.3 ISMS team

The ISMS team, led by the ISMS manager, runs the system day to day. It maintains the document set, runs the risk assessment cycle, tracks corrective actions, plans audits, collects indicators, supports control owners and prepares the management review.

• Core members: the ISMS manager, the security analyst and the compliance coordinator, supported by a representative from each function who acts as a security champion.
• Security champions spend about [10%] of their time on security tasks and meet the team [monthly].
• The team reports to the Chief Information Security Officer and has the right to raise any matter directly with top management.

5.4 Roles and responsibilities

5.5 RACI for main ISMS activities

5.6 Escalation of security matters

6. ISMS Review and Improvement

The ISMS is reviewed and improved through measurement, internal audit, management review and corrective action. These activities are scheduled in the ISMS Compliance Scheduled Activities Plan.

6.1 Monitoring and measurement

Each control owner reports the indicators for their area on the schedule agreed in the ISMS Compliance Scheduled Activities Plan. The ISMS manager consolidates them and reports to the steering committee. An indicator that is missed twice running prompts a corrective action.

6.2 Internal audit

Internal audit checks that the ISMS conforms to this policy and to the standard, and that it is effective. An annual programme covers all in-scope processes and controls, using more frequent audits for higher-risk areas. Auditors are independent of the area they audit and are competent in the method. Findings are graded, reported within [10 working days] of the closing meeting and tracked to closure.

6.3 Management review

Top management reviews the ISMS at least every [12 months] and in practice [twice a year]. The review considers:

• status of actions from earlier reviews and changes in internal and external issues;
• feedback from interested parties, including customers and regulators;
• performance against objectives, indicators, audit results and incident trends;
• results of risk assessment and the status of the risk treatment plan;
• opportunities for improvement and any need to change policy, scope or resources.

The output is a set of decisions and actions with owners and dates, recorded in minutes that are kept as ISMS records.

6.4 Nonconformity and corrective action

1. RecordAnyone who finds a nonconformity records it in [the ticketing tool] with source, evidence and affected control; the ISMS manager acknowledges within [2 working days].
2. ContainThe control owner takes immediate action to limit harm or to correct the situation within [5 working days].
3. Find the causeThe control owner and the ISMS manager find the root cause, not only the symptom, within [15 working days].
4. ActA corrective action with owner and due date is approved; the due date is no later than [60 days] unless the steering committee agrees otherwise.
5. VerifyThe ISMS manager checks, after [30 days] of operation, that the action worked and the nonconformity did not recur, then closes it.

6.5 Continual improvement

Improvements come from audits, incidents, near misses, staff suggestions, supplier reports, changes in threats and the opportunities identified at management review. They are entered in the improvement log, ranked by risk reduction and effort, and reported at each steering committee meeting. A change that alters a policy is made through document control.

7. How to Read the Controls

The remainder of this policy takes the Annex A controls theme by theme, in the order of the standard. Every control has the same shape, so a reader can find what is needed quickly.

7.1 Shape of each control

• The heading gives the Annex A identifier and the control title.
• The opening paragraphs are the policy statement: what the Organisation requires, who is accountable and how the requirement is met in practice.
• The list that follows holds testable requirements. Each can be checked by an auditor with evidence.
• The last paragraph begins 'Implemented through' and names the library documents that carry the detail, then says what evidence shows the control works.
• Where a control is naturally a table, such as classification levels, a table is added.

7.2 Wording conventions

• 'Must' states a requirement. 'Should' states a good practice that may be set aside with a recorded reason. 'May' states a permission.
• A value in square brackets is a default that the adopting organisation must confirm or change to fit its risk. A bracketed value is never silent: it is either kept or replaced.
• References to law carry a note to confirm the current requirement, because the library does not give legal advice.
• Titles written in full, such as the Access Control Policy, are exact titles of documents in the library.

7.3 Where the controls sit

Where two controls are close, the text of each draws the line between them. For example, identity management concerns the existence and life of an identity, access rights concern what that identity may do, and authentication information concerns the secret that proves it.

7.4 Evidence and the Statement of Applicability

The evidence named in each control is what an auditor will ask to see. The Statement of Applicability lists each control, whether it applies, where it is implemented and the status. A control owner who cannot produce the evidence named for a control records a nonconformity.

8. Organizational controls

Organizational controls set the rules that govern the Organisation as a whole: its policies and roles, its inventory and handling of information, who may access what, its dealings with suppliers, how it responds to incidents and disruption, and how it stays within the law and checks itself. They are owned by the Chief Information Security Officer together with the owners named in each control.

8.1 A.5.1 Policies for information security

Top management approves this Information Security Policy and the topic-specific policies beneath it. Each policy has a named owner, a version number and an approval date, and is published in [the document management system], where every person in scope can read it. A statement that cannot be checked is rewritten or removed at the next review.

The Chief Information Security Officer is accountable for keeping the set complete and consistent. The steering committee decides when a topic needs its own policy. A policy change is announced to affected people within [10 working days] of approval, with a request to confirm they have read it.

• Every policy must carry an owner, version, approval date and next review date in its revision history.
• Policies must be reviewed at least every [12 months] and after a significant incident, change of law or change of scope.
• Top management must approve a new or materially changed policy before it takes effect.
• A superseded version must be withdrawn from circulation within [5 working days] and archived read-only.
• Read-and-acknowledge completion for a new or changed policy must reach [95%] within [30 days].

Implemented through the ISMS Manual, the Documents and Records Management Procedure and the ISMS Compliance Scheduled Activities Plan. Evidence is the policy register, approval minutes and the acknowledgement report.

8.2 A.5.2 Information security roles and responsibilities

Every information security responsibility has a named role, and every role has a named holder. Top management appoints the Chief Information Security Officer, the Data Protection Officer and the ISMS manager in writing, and states the authority each has, including the right to stop a release or a connection that creates unacceptable risk.

Asset owners, risk owners, system administrators and line managers carry the duties set by the policy that governs their area. Job descriptions, supplier contracts and project charters repeat the duties that apply to the role, so that no duty depends on goodwill.

• Each role in the ISMS role table must have a named holder and a named deputy recorded in [the document management system].
• An appointment or change of holder must be recorded within [5 working days].
• Job descriptions for roles with security duties must state those duties, and HR must confirm this at hire and at each role change.
• Every asset, risk and policy must have an owner, and an item with no owner after [30 days] must be escalated to the steering committee.
• No ISMS role may be vacant for more than [10 working days] without cover approved by top management.

Implemented through the ISMS Manual, the HR Security Policy, the HR Security Procedure and the HR Succession Planning Policy. Evidence is the role register, signed appointment letters and the vacancy report.

8.3 A.5.3 Segregation of duties

Where one person could misuse a critical process, bypass a control or hide an error, the Organisation splits the process so that a second person must act. The conflicts that matter most are requesting and approving access, writing and promoting code to production, raising and releasing a payment, and administering a system while auditing its logs.

Where a split is impossible, as in a small team, the risk owner approves a compensating control such as independent log review, dual approval or rotation of duty. Conflict rules are held as a matrix and checked each time access is granted.

• The ISMS team must maintain a matrix of incompatible duties and review it every [12 months].
• The same person must not request, approve and carry out an access change, a production change or a payment release.
• Access tools must block or flag any grant that creates a conflict listed in the matrix.
• Each accepted conflict must have a compensating control, a risk owner and an end date no later than [6 months].
• Administrators must not hold audit or log-deletion rights over the systems they administer.

Implemented through the Access Control Policy, the User Access Management Procedure, the Change Management Policy and Procedure and the System Development and Maintenance Procedure. Evidence is the conflict matrix, access reviews that list exceptions, and change records showing distinct requester and approver.

8.4 A.5.4 Management responsibilities

Managers at every level are accountable for the security conduct of the people and suppliers who report to them. They make sure that new joiners and contractors complete induction before receiving access, that teams follow the policies that apply to their work, and that concerns are raised and acted on rather than hidden.

Managers also set the example: they use approved tools, report mistakes quickly and attend training. Top management reviews how well managers discharge these duties as part of management review and takes the result into account at appraisal.

• A manager must confirm that each new team member has completed induction security training before access beyond the basic set is granted.
• A manager must complete the quarterly access review for the team within [10 working days] of the request.
• A manager who learns of a suspected incident must report it to [the service desk] within [1 hour].
• Each manager must sign an annual attestation that the team follows the policies relevant to its work.
• Security objectives must be part of every manager's goals and be reviewed at each appraisal cycle.

Implemented through the HR Security Policy, the HR Security Procedure, the Acceptable Usage Policy and the Information Security Monitoring and Compliance Policy. Evidence is induction sign-offs, attestation returns and review completion rates by team.

8.5 A.5.5 Contact with authorities

The Organisation keeps defined, tested channels to the bodies it may need to inform or ask for help: the national cyber emergency response team, law enforcement, sectoral regulators, the data protection authority, emergency services and the utilities serving its premises. Only authorised people make contact on its behalf, which prevents inconsistent or premature disclosure.

The Chief Information Security Officer holds the contact list and legal counsel decides what is disclosed and when. Under the CERT-In Directions of 28 April 2022, cyber incidents are reported within 6 hours of noticing them [confirm the current requirement].

• The authority contact list must record the body, purpose, channel, authorised caller and last verification date, and be verified every [6 months].
• Only the Chief Information Security Officer, the Data Protection Officer or a named deputy may report to an authority, unless legal counsel delegates in writing.
• The incident procedure must state the reporting deadline for each authority and hold a report template.
• Every report to an authority must be logged with the time of detection, time of submission and the person who filed it.
• A reporting drill must be run at least every [12 months].

Implemented through the Information Security Incident Management Policy, the Incident Management Procedure, the Data Protection Act Compliance Procedure and the Public Policy Advocacy and Regulatory Engagement Policy. Evidence is the contact list, the report log and the drill report.

8.6 A.5.6 Contact with special interest groups

Membership of professional forums, industry sharing groups and product security advisories keeps the Organisation current with threats, good practice and weaknesses in products it uses. It joins only groups it can contribute to and that have a sensible confidentiality arrangement. This control is about the relationships; the handling of the intelligence they provide is set under threat intelligence.

Information shared with a group never identifies a customer or reveals internal architecture or an unresolved weakness. The ISMS team nominates one member per group and records what was learned, so that membership produces improvements and does not remain a line on a list.

• The ISMS team must keep a register of groups, the nominated member, the reason for membership and the last learning recorded.
• Each membership must be reviewed every [12 months] and dropped if it gave no useful input.
• Nothing may be shared that identifies a customer, contains personal data or describes an unresolved weakness in the Organisation's systems.
• Sharing under a traffic-light or similar protocol must follow the marking set by the originator.
• Learning that affects a control must be raised as an improvement action within [10 working days].

Implemented through the Threat Intelligence Policy, the Public Policy Advocacy and Regulatory Engagement Policy and the ISMS Compliance Scheduled Activities Plan. Evidence is the group register, notes of what was learned and the improvement log entries that resulted.

8.7 A.5.7 Threat intelligence

The Organisation collects threat information from selected internal and external sources, analyses it for relevance to its own technology and customers, and turns it into action. Sources include security advisories, vulnerability feeds, incident data from its own logs and information from trusted groups.

Each item is rated for relevance and urgency, and used at three levels: a strategic briefing for top management, an operational notice of a campaign to the defence teams, and technical indicators loaded into detection tools. Intelligence that is not read, rated and acted on is treated as a failure of the process.

• A list of approved intelligence sources must be kept and reviewed every [12 months].
• Every item rated critical must be triaged within [4 hours] and a decision recorded.
• Indicators of compromise accepted for use must be loaded into detection tools within [1 working day] and carry an expiry date.
• A threat summary must be given to the steering committee every [quarter].
• Each action taken from intelligence must be logged with its source for traceability.

Implemented through the Threat Intelligence Policy, the Patch Management Procedure, the Vulnerability Assessment and Penetration Testing Procedure and the Logging and Monitoring Procedure. Evidence is the triage log, indicator load records and the quarterly summary.

8.8 A.5.8 Information security in project management

Security is part of every project, whatever its size or method: software, infrastructure, process change or the adoption of a service. At initiation the project manager records the information involved, its classification and the legal and contractual requirements, and the ISMS team decides whether a full risk assessment is needed.

Security requirements enter the business case, and a named security contact signs off at design approval, go-live and closure. Risks found go to the project risk log and, where residual risk is above appetite, to the corporate risk register. Changes in scope during delivery trigger a fresh screening.

• Every project must complete a short security screening at initiation that records data types, classification and external parties.
• A project scored [medium] or above must complete a documented risk assessment before design approval.
• Security requirements must be listed in the project plan and traced to test results before go-live.
• A security sign-off must be recorded at each stage gate; a project must not go live with an open high risk unless the risk owner accepts it in writing.
• Security lessons must be recorded at project closure.

Implemented through the Risk Management Policy, the Product Risk Assessment Procedure, the Systems Acquisition, Development and Maintenance Policy and the Change Management Policy and Procedure. Evidence is the screening forms, stage-gate sign-offs and the project risk log.

8.9 A.5.9 Inventory of information and other associated assets

The Organisation knows what it must protect. It keeps one inventory of information assets, systems, applications, devices, cloud services and premises, and each entry names an owner, a classification, a location and the business process it supports.

Owners are accountable for the accuracy of their entries and for protecting the asset through its life. Discovery tools feed the inventory wherever possible, and it is reconciled with finance, procurement and HR records so that unknown or orphaned assets are found and dealt with. Cloud accounts, subscriptions and software-as-a-service tenants are counted as assets, not only physical equipment.

• Each asset record must hold owner, custodian, classification, location, business process, acquisition date and expected end-of-life date.
• A new asset must be recorded before it is put into use, and a retired asset marked as such within [5 working days].
• Discovery scans must be reconciled with the inventory at least [monthly], and an unknown device investigated within [2 working days].
• Owners must confirm the accuracy of their entries at least every [12 months].
• Information must be listed by information type as well as by system, so that classification and retention can be applied.

Implemented through the IT Asset Management Policy, the Asset Management Procedure and the Data Governance Policy. Evidence is the inventory export, reconciliation reports and owner confirmations.

8.10 A.5.10 Acceptable use of information and other associated assets

Anyone who uses the Organisation's information and assets must use them for authorised business purposes and in a way that protects them. The rules cover email, messaging, internet, software, removable media, personal devices, social media and generative AI tools. Limited personal use is allowed when it harms neither productivity, security nor reputation.

Users learn the rules at induction and confirm them each year. They are told what monitoring takes place and why. Breaches are handled through the disciplinary process. Managers are told of repeated or serious breaches, and the Chief Information Security Officer may suspend access at once while a breach is investigated.

• Users must acknowledge the acceptable use rules on joining and every [12 months].
• Users must not install unapproved software, connect unapproved storage or send classified information outside approved channels.
• Information classified [Confidential] or above must not be entered into any public generative AI service.
• Users must report the loss, theft or suspected misuse of an asset within [1 hour] of discovering it.
• Corporate accounts must not be used to register for services unrelated to work.

Implemented through the Acceptable Usage Policy, the Employee AI Usage Policy and the Mobile Device and Teleworking Policy. Evidence is acknowledgement records, web and data-loss alerts, and disciplinary case records.

8.11 A.5.11 Return of assets

When employment, a contract or an agreement ends, or a role changes so that an asset is no longer needed, everything issued is returned: laptops, phones, tokens, access cards, keys, documents, and Organisation data held on personal devices. The line manager starts the return on the leaving checklist, IT confirms the condition of each device and facilities recovers physical credentials.

Where a person is dismissed or leaves on poor terms, access is withdrawn first and return is arranged on the same day. Unreturned items are escalated and recorded as losses.

• The leaving checklist must list every asset on the person's assignment record and be signed by the line manager and IT on or before the last working day.
• Devices must be returned within [2 working days] of the leaving date, or collected by courier within [5 working days] for remote staff.
• Organisation data on personal devices must be removed, and the person must confirm in writing that no copies remain.
• Unreturned items must be escalated to the HR lead after [5 working days].
• Returned devices must be re-imaged or securely wiped before reissue.

Implemented through the HR Security Procedure, the Asset Management Procedure, the Asset Disposal Process and the Mobile Device Management Procedure. Evidence is signed leaving checklists, reconciliation of assignment records and wipe certificates.

8.12 A.5.12 Classification of information

Information is classified by its value, legal requirements, sensitivity and the harm that its disclosure, alteration or loss would cause. The owner assigns the level when the information is created or received, and a collection takes the highest level of anything in it. Storage, sharing, encryption, retention and disposal all follow the level.

Customer information is classified in line with customer instructions, and no lower than [Confidential] unless the customer says otherwise in writing. Owners review the level when sensitivity changes, for example after publication. Where a level is disputed, the Data Protection Officer or the Chief Information Security Officer decides, and the decision is recorded.

• Owners must classify information at creation or receipt, and bulk intake within [5 working days].
• Unclassified information must be treated as [Internal] until it is assessed.
• Classification of [Confidential] and above must be reviewed at least every [12 months].
• A request to lower a classification must be approved by the information owner and recorded.

Implemented through the Information Classification and Handling Policy, the Information Classification and Handling Procedure and the Data Governance Policy. Evidence is the classification register and sample audits of documents against their level.

8.13 A.5.13 Labelling of information

Labels tell people and systems how to handle information. Classifying decides the level; labelling makes the level visible so that it travels with the information. Documents carry the label in the header or footer and in file properties, emails in the subject line or an automatic banner, and printouts and removable media on the cover or a sticker.

Where a label cannot be shown, as in a database, the classification is recorded in system metadata or the data catalogue. Labels on information received from customers are kept or mapped to the Organisation's levels.

• Documents classified [Confidential] or above must show the label on every page and in file properties.
• Outbound email that carries classified information must show the label in the subject line or an automatic banner.
• Labelled templates must be provided in [the document management system] so that no manual typing is needed.
• Printed copies and removable media must be labelled before they leave the owner's desk.
• A mislabelled item must be corrected and recorded, and repeated cases reported to the information owner.

Implemented through the Information Classification and Handling Procedure, the Information Classification and Handling Policy and the Data Governance Policy. Evidence is a quarterly sample of [20] documents checked for correct labels, with the compliance rate reported.

8.14 A.5.14 Information transfer

Information leaves the Organisation by email, file transfer, portable media, courier, telephone, messaging and collaboration tools. For each channel the Organisation defines the highest classification it may carry, the protection required and the record to keep. Staff use approved channels and never personal accounts to send business information.

Transfers to third parties are covered by an agreement or non-disclosure agreement that names the permitted use and requires return or deletion afterwards. Personal data sent abroad follows the rules for cross-border transfers. The Chief Information Security Officer approves any new channel before staff may use it.

• The recipient's identity and authority must be verified before classified information is sent, and a bulk transfer needs the owner's approval.
• An external transfer must be covered by a signed agreement or non-disclosure agreement before the first transfer.
• Links shared externally must expire within [7 days] and be revoked when the purpose is complete.
• Information classified [Confidential] or above must be encrypted in transit and when stored by the recipient.
• Transfers of Restricted information, and of personal data across borders, must be logged and approved by [the Data Protection Officer].

Implemented through the Information Classification and Handling Procedure, the Cryptography Policy, the Data Protection and Privacy Procedure and the Communications and Operations Security Policy. Evidence is transfer logs, signed agreements and data-loss prevention reports.

8.15 A.5.15 Access control

Access is granted on the principles of need to know and least privilege, and is denied unless explicitly permitted. Business owners decide who needs access to their information and systems, and write the decision as access rules per system or role. The same rules apply to employees, contractors, suppliers and automated accounts.

This control sets the rules. Identity management, authentication information and access rights carry them out: they register the identity, prove it and attach the permissions. Exceptions to an access rule are time-limited, approved by the information owner and recorded, so that a shortcut taken in an emergency does not become the normal way of working.

• Every system must have documented access rules naming roles, permitted actions and the owner who approves access.
• Default access must be none; access must be granted by role where a role exists, and otherwise by named approval.
• Access to Restricted information must be approved by the information owner and logged.
• Shared and generic accounts must be prohibited unless the system owner records the reason and a named custodian.
• Access rules must be reviewed when a system changes and at least every [12 months].

Implemented through the Access Control Policy and the User Access Management Procedure. Evidence is the access rule sets, owner approvals and access review results.

8.16 A.5.16 Identity management

Every person, device and service that uses the Organisation's systems has a unique identity that traces to one accountable owner. HR is the source of truth for staff, procurement for suppliers and the system owner for service accounts. An identity is created when authorised, changed when circumstances change, suspended when unused and deleted after a retention period.

This control concerns the identity itself and its life. What the identity may do is decided under access rights, and the secret that proves it under authentication information. Every identity can be traced in the logs to a person or a named owner.

• Each identity must be unique, linked to one person or one named owner, and recorded in [the directory service].
• A staff identity must be created only from an approved HR record and disabled on the last working day, or at once on dismissal.
• Accounts inactive for [60 days] must be disabled and those inactive for [180 days] deleted after review.
• Service and machine identities must have a named owner and a review date no more than [12 months] ahead.
• Duplicate or orphaned identities found by reconciliation must be resolved within [10 working days].

Implemented through the User Access Management Procedure, the HR Security Procedure and the Access Control Policy. Evidence is directory reconciliation reports, joiner and leaver tickets and inactive account reports.

8.17 A.5.17 Authentication information

Secrets that prove identity, such as passwords, passphrases, tokens, certificates, keys and recovery codes, are protected throughout their life: issued securely, changed on compromise, never shared and never stored in clear text. The Organisation prefers long passphrases and multi-factor authentication to frequent forced change, and blocks known-compromised values.

People keep secrets only in [the password manager]. This control concerns how secrets are handled; how strong authentication is enforced by systems is set under secure authentication. Anyone who finds a secret exposed, for example in a chat message or a code repository, treats it as compromised and reports it immediately.

• Passwords must be at least [14] characters and be checked against a blocklist of breached and common values.
• Multi-factor authentication must be required for remote access, administrators and every system holding Confidential or higher information.
• Initial and reset credentials must be issued over a separate channel and expire within [24 hours] if unused.
• A secret must be changed within [24 hours] of suspected compromise and must never be shared, written down or sent by email.
• Secrets in code or configuration must be held in a secrets vault, and repositories must be scanned for leaked secrets.

Implemented through the Access Control Policy, the Cryptography Procedure, the Key Management Process and the Acceptable Usage Policy. Evidence is password policy settings, multi-factor coverage reports and secret scan results.

8.18 A.5.18 Access rights

Access rights are the specific permissions given to an identity. They are provisioned only on a recorded request approved by the information owner, changed when a person moves and withdrawn when no longer needed. Standard role profiles keep requests quick and consistent.

Identities answer who; rights answer what that identity may do. Owners review rights regularly, because rights accumulate as people change roles, and privileged rights receive extra scrutiny. Rights are never granted because a colleague has them, and temporary rights expire automatically. A manager cannot approve access to information that belongs to another owner.

• A request must name the requester, system, level of access and business reason, include an expiry date for temporary access, and be approved by the owner before provisioning.
• Provisioning must be completed within [2 working days] of approval, and revoked within [1 working day] of a leaver or role change.
• User access reviews must be run [quarterly] for systems with Confidential data and every [12 months] for others.
• Reviewers must confirm or remove every right, and removals must be done within [5 working days].
• Privileged rights must be time-limited and reviewed every [3 months].

Implemented through the User Access Management Procedure, the Access Control Policy and the HR Security Procedure. Evidence is access request records, review sign-offs and removal tickets.

8.19 A.5.19 Information security in supplier relationships

Suppliers that handle the Organisation's information or support its systems expose it to risk. Before an engagement the business owner identifies the information involved and the access needed, and the ISMS team rates the supplier by criticality. The rating sets the due diligence, contract terms, monitoring and exit planning required.

A single register records each supplier's owner, services, rating, data held, contract dates and reviews. No supplier receives access until the checks for its tier are complete and the contract is signed. Criticality is reassessed whenever the service, the data or the supplier's circumstances change.

• Every supplier must be rated in the supplier register before the contract is signed.
• A critical supplier must complete due diligence, including evidence of its controls, before access is granted.
• Supplier access must be limited to what the service needs and ended on exit.
• Each supplier must have a named relationship owner in the Organisation.
• The supplier register must be reviewed every [6 months].

Implemented through the Supplier Relationship Management Policy, the Supplier Relationship Management Procedure and the Risk Management Policy. Evidence is the supplier register, completed due diligence files and tier ratings.

8.20 A.5.20 Addressing information security within supplier agreements

Contracts turn security expectations into obligations. Agreements with suppliers who handle information or support systems state what information is covered, permitted use, minimum controls, screening of their people, subcontracting rules, incident notification, audit rights and return or deletion at exit. This control is about the contract; the due diligence that precedes it is set under supplier relationships.

Legal counsel maintains standard clauses by supplier tier. Any departure is approved by the Chief Information Security Officer before signature. Standard terms are never traded away for price or speed without a recorded risk acceptance by the risk owner.

• An agreement must include a security schedule matching the supplier's tier.
• A supplier must notify the Organisation of a security incident affecting its information within [12 hours] of becoming aware.
• Subcontracting must need prior written consent, and security terms must flow down to the subcontractor.
• The Organisation must hold the right to assess or audit a critical supplier at least every [12 months].
• At exit the supplier must return or securely delete the Organisation's information and confirm it in writing within [30 days].

Implemented through the Supplier Relationship Management Procedure, the Supplier Relationship Management Policy and the Data Protection and Privacy Procedure. Evidence is signed agreements, the clause library and exit confirmation letters.

8.21 A.5.21 Managing information security in the ICT supply chain

ICT products and services depend on layers of suppliers, from hardware makers and software authors to cloud platforms and their subcontractors. The Organisation requires its direct suppliers to pass its security requirements down the chain and to disclose critical dependencies. Where 'supplier relationships' covers the direct relationship, this control covers the depth of the chain and the components within it.

Open-source and third-party components are tracked in a software bill of materials, and tampering risk is reduced by receiving hardware through approved channels. Where a critical component has a single source, the dependency is recorded as a risk.

• A critical ICT supplier must disclose its subcontractors and the locations where service is delivered.
• A software bill of materials must be kept for each application the Organisation develops, and updated at each release.
• A component within [90 days] of end of support must have a replacement plan.
• Hardware must come from approved suppliers, and seals, serial numbers and firmware versions must be checked on receipt.
• A concentration review of critical dependencies must be done every [12 months], with alternatives noted.

Implemented through the Supplier Relationship Management Policy, the Systems Acquisition, Development and Maintenance Policy, the IT Asset Management Policy and the Patch Management Policy. Evidence is bills of materials, supplier disclosure statements and receipt inspection records.

8.22 A.5.22 Monitoring, review and change management of supplier services

Security assurance continues after signature. Relationship owners review supplier performance against the agreed service levels and security obligations, using reports, audit results, incident history and independent assurance. Changes by a supplier to its service, location, subcontractors or controls are assessed for risk before they take effect, and changes requested by the Organisation go through change management.

Issues are tracked to closure, and persistent failure triggers an improvement plan, a contractual remedy or, if needed, exit. Exit plans for critical suppliers are rehearsed on paper at least once a year, so that leaving is possible without disruption.

• A critical supplier must be reviewed [quarterly] and an important supplier [annually], with the review recorded in the supplier register.
• Supplier security and assurance reports must be collected and checked for scope, date and exceptions.
• A supplier notice of change must be assessed within [10 working days] and approved before it applies to Organisation data.
• A supplier incident must be logged in the incident register and reviewed for impact on the Organisation.
• Findings must have an owner and due date, and be escalated when [30 days] overdue.

Implemented through the Supplier Relationship Management Procedure, the Change Management Policy and Procedure, the Incident Management Procedure and the Information Security Monitoring and Compliance Policy. Evidence is review minutes, assurance report assessments and the findings tracker.

8.23 A.5.23 Information security for use of cloud services

Cloud services are adopted, used and exited under rules that fit their shared-responsibility nature. Before use, the business owner and ISMS team assess the service for suitability to the data classification, storage and processing location, tenant isolation, encryption, logging, resilience and exit options. Each service has an owner and a documented split of duties with the provider.

Services bought without approval are detected and either regularised or stopped. At exit, data is returned or deleted and evidence of deletion obtained. Personal accounts on consumer services are never used for work, whatever their convenience.

• No cloud service may hold Confidential or Restricted data without a completed assessment approved by the Chief Information Security Officer.
• The split of responsibilities between the Organisation and the provider must be documented for each service.
• Storage and processing locations must meet legal and contractual restrictions.
• Cloud configuration must be checked against a baseline continuously, and drift fixed within [5 working days].
• Administrator accounts must use multi-factor authentication, and a discovery check for unapproved services must run [quarterly].

Implemented through the Cloud Computing Security Policy and Procedure, the Secure Configuration Policy, the Supplier Relationship Management Procedure and the Cryptography Policy. Evidence is service assessments, configuration scan reports and the cloud service register.

8.24 A.5.24 Information security incident management planning and preparation

Incidents are handled well because they are prepared for. The Organisation defines what counts as an information security event and an incident, who responds, how they are reached and what authority they hold. A response team with defined roles, an on-call rota and a communications plan is in place, and playbooks cover the likeliest scenarios: ransomware, account takeover, data leakage and loss of a device.

The plan is exercised so that people practise before they are tested for real. Lessons from real incidents and exercises flow back into the playbooks within a defined period.

• A response team with named members, deputies and an on-call rota must be maintained and reachable within [30 minutes] outside office hours.
• Playbooks must exist for at least [five] scenarios and be reviewed every [12 months].
• A tabletop exercise must be run at least every [6 months] and a technical simulation every [12 months].
• Incident tooling and the out-of-band communication channel must be tested every [quarter].
• The reporting route must appear in induction material and on the intranet.

Implemented through the Information Security Incident Management Policy, the Incident Management Procedure and the Information Security Aspects of Business Continuity Policy. Evidence is the rota, playbook library, exercise reports and tool test records.

8.25 A.5.25 Assessment and decision on information security events

Every reported or detected event is assessed promptly, so that real incidents get the right response and false alarms are closed without waste. The service desk or monitoring team records the event, the incident coordinator assesses its type, the systems and data affected, and assigns a severity from the matrix. The decision to declare an incident, and the reasoning, are recorded.

Events involving personal data go to the Data Protection Officer at once. The assessment is repeated whenever new facts arrive, and severity can be raised or lowered. Disagreements are resolved by the Chief Information Security Officer.

• Every reported event must be logged and acknowledged within [30 minutes] during working hours.
• A severity must be assigned and a declare-or-close decision taken within [1 hour] of acknowledgement for events that may be High or Critical.
• The reason for closing an event as a non-incident must be recorded.
• An event involving personal data must be referred to the Data Protection Officer within [2 hours].
• Severity must be reassessed whenever a material new fact is found.

Implemented through the Incident Management Procedure, the Information Security Incident Management Policy, the Logging and Monitoring Procedure and the Data Protection Act Compliance Procedure. Evidence is the incident register, triage notes and severity decisions.

8.26 A.5.26 Response to information security incidents

Declared incidents are managed through five phases: contain, investigate, eradicate, recover and communicate. The incident coordinator leads, keeps a timeline of decisions and has authority to isolate systems, suspend accounts or take services offline when the harm warrants it. Responders follow playbooks, preserve evidence before changing anything and escalate by severity.

Management, legal counsel, customers and regulators are told what they need to know, when they need to know it, through the communications lead only. An incident is closed only when systems are restored, the cause is addressed and the record is complete.

• Containment of a Critical or High incident must start within the response time of the severity matrix, and each action must be logged with time and person.
• Evidence must be preserved before systems are rebuilt.
• The Chief Information Security Officer must be told of a Critical incident within [30 minutes] and top management within [2 hours].
• Notification to authorities, customers and affected individuals must be decided by legal counsel and the Data Protection Officer and sent within the legal deadlines.
• Closure must require a restoration check, a root-cause statement and a scheduled review.

Implemented through the Incident Management Procedure, the Information Security Incident Management Policy, the BCP and DR Procedure and the Data Protection Act Compliance Procedure. Evidence is the incident timeline, action log and closure checklist.

8.27 A.5.27 Learning from information security incidents

Every incident of Medium severity and above, and every near miss that exposes a weakness, ends in a review. It asks what happened, how it was detected, what worked and failed, the root cause and what must change. The tone is blameless, so people give an honest account.

Corrective actions get an owner and a date and are tracked until verified. Incident data is analysed [quarterly] for trends and repeat causes, and lessons are fed into risk assessments, playbooks, awareness material and control design. The Chief Information Security Officer reports repeated causes to top management.

• A post-incident review must be held within [10 working days] of closing a High or Critical incident.
• Each review must record root cause, contributing factors, time to detect, and time to contain and to recover.
• Corrective actions must have an owner and a due date and be verified for effect within [60 days].
• A trend analysis of incidents must go to the steering committee every [quarter].
• Playbooks and awareness material must be updated within [30 days] of a lesson being accepted.

Implemented through the Incident Management Procedure, the Problem Management Policy and Process, the Information Security Incident Management Policy and the Risk Management Policy. Evidence is review reports, the corrective action tracker and trend reports.

8.28 A.5.28 Collection of evidence

When an incident may lead to disciplinary action, a legal claim or a report to an authority, evidence is identified, collected, acquired and preserved so that it will withstand scrutiny. Only trained or authorised people collect it. They record who handled it, when, where and why, make forensic copies rather than work on originals, and compute hashes at collection.

Legal counsel decides when to move to formal forensic handling. ICT logs are kept for 180 days within Indian jurisdiction under the CERT-In Directions of 28 April 2022 [confirm the current requirement].

• A chain-of-custody record must accompany every evidence item from collection to disposal.
• Analysis must be carried out on forensic copies, with hash values checked before and after.
• Only staff on the forensic list or an approved external specialist may collect evidence.
• Evidence must be stored in an access-restricted, logged location and kept for the period set by legal counsel, at least [12 months] after closure.
• Legal counsel must advise before evidence is taken from a personal device or from monitoring of staff.

Implemented through the Incident Management Procedure, the Logging and Monitoring Procedure, the Documents and Records Management Procedure and the Information Security Incident Management Policy. Evidence is chain-of-custody forms, hash records and the evidence store access log.

8.29 A.5.29 Information security during disruption

Security does not stop when operations are disrupted. When continuity or recovery plans are invoked, the Organisation keeps confidentiality, integrity and availability at an agreed level and avoids shortcuts that create worse exposure, such as disabling controls, sharing credentials or moving data to unapproved tools.

Each continuity plan names the controls that must stay in force, the ones that may be relaxed temporarily under approval, and how relaxations are tracked and reversed. Alternative sites, remote working and manual workarounds follow the same rules. Staff are told which temporary arrangements are in force and when they end.

• Each continuity plan must list the controls that stay in force during disruption, such as access control, logging and encryption, and any relaxation permitted with the approving role.
• A relaxation must be approved by the Chief Information Security Officer or deputy, limited to [72 hours] unless renewed, and recorded.
• Backup and alternate sites must give the same classification-based protection as the primary.
• After recovery, a check must confirm that every relaxed control was restored within [5 working days].
• Disruption exercises must include security scenarios such as ransomware and loss of a site.

Implemented through the Information Security Aspects of Business Continuity Policy, the BCP and DR Procedure, the Backup and Restoration Policy and the Information Security Incident Management Policy. Evidence is continuity plans, relaxation approvals and post-recovery control checks.

8.30 A.5.30 ICT readiness for business continuity

ICT services that support critical processes are made ready to meet the recovery objectives set by the business impact analysis. For each critical service, owners agree a recovery time objective and a recovery point objective, and IT designs backup, redundancy, spare capacity and runbooks to achieve them.

Readiness is proved by tests, not asserted: restores are performed, failovers exercised and results compared with the objectives. Gaps go to the steering committee with a plan and a date. Changes to systems, suppliers or processes trigger a review of the objectives that apply to them.

• Every critical service must have recovery time and recovery point objectives approved by its business owner.
• Recovery runbooks must be available offline and tested at least every [12 months] for Tier 1 services.
• A sample restore from backup must succeed [monthly].
• A shortfall against objectives must be raised as a risk within [10 working days].
• Plans must cover dependencies such as network, identity, name resolution and critical suppliers.

Implemented through the BCP and DR Procedure, the Information Security Aspects of Business Continuity Policy, the Backup Management and Retention Procedure and the Capacity Management and Planning Procedure. Evidence is business impact analyses, test reports and restore logs.

8.31 A.5.31 Legal, statutory, regulatory and contractual requirements

The Organisation identifies, documents and keeps current the legal, regulatory and contractual obligations that touch information security and privacy in each jurisdiction where it operates or holds data. Legal counsel owns the register, and control owners turn each obligation into a control and evidence.

In India the register covers the Information Technology Act, 2000, the Digital Personal Data Protection Act, 2023 and its Rules, and the CERT-In Directions of 28 April 2022 [confirm the current requirement]. For other places it covers applicable law in each jurisdiction where the Organisation operates (such as the EU General Data Protection Regulation).

• The register must record each obligation, its source, the control that meets it, the owner, the evidence and the next review date.
• The register must be reviewed [quarterly], and legal counsel must report a relevant change within [10 working days].
• A contract that carries security terms must be logged, and its commitments checked against capability before signature.
• A new product or market must receive legal review of obligations before launch.
• Internal audit must sample the evidence for obligations each year.

Implemented through the Information Security Monitoring and Compliance Policy, the Cyber Compliance Plan, the Data Protection Act Compliance Procedure and the Public Policy Advocacy and Regulatory Engagement Policy. Evidence is the legal register, review minutes and audit samples.

8.32 A.5.32 Intellectual property rights

The Organisation respects the intellectual property of others and protects its own. It uses software, data sets, fonts, images and content only under a valid licence, and tracks entitlements against installations. Open-source components are used within their licence terms, which are reviewed before adoption.

Employees and contractors assign rights in work created for the Organisation through their agreements, and do not bring in or use code, documents or confidential information belonging to a previous employer or client. The Organisation's own source code, designs and brand assets are classified and protected.

• Software must be installed only from the approved catalogue and counted against licence entitlements at least every [6 months].
• The licence of an open-source component must be reviewed and approved before first use in a product.
• Contracts of employment and service must assign rights in work created for the Organisation.
• Unlicensed software found must be removed within [5 working days] and the cause recorded.
• Licence agreements, purchase records and keys must be kept for the licence life plus [6 years].

Implemented through the Acceptable Usage Policy, the IT Asset Management Policy, the Systems Acquisition, Development and Maintenance Policy and the HR Security Policy. Evidence is licence reconciliations, open-source approvals and signed rights assignments.

8.33 A.5.33 Protection of records

Records that evidence decisions, transactions, compliance and obligations are kept as long as law, contract and business need require, and are protected against loss, destruction, falsification and unauthorised access. A retention schedule fixes the period and owner of each record type, and records are stored so that they stay readable for the whole period.

At the end of the period, records are checked for any legal hold and then securely destroyed, with evidence of destruction. Records held for customers follow the retention period in the contract. Where law and contract differ, the longer period applies unless legal counsel decides otherwise.

• The retention schedule must be approved by legal counsel and reviewed every [12 months].
• Records must be held in versioned or write-protected storage with access limited to their owners.
• A legal hold must override scheduled destruction and be released only by legal counsel.
• Destruction must be logged with the record type, date, method and approver.
• The integrity of records kept longer than [3 years] must be checked every [12 months].

Implemented through the Documents and Records Management Procedure, the Backup Management and Retention Procedure, the Data Governance Policy and the Asset Disposal Process. Evidence is the retention schedule, destruction log and integrity check results.

8.34 A.5.34 Privacy and protection of PII

The Organisation processes personal data lawfully, fairly and only for stated purposes, and keeps only what it needs for as long as it needs. The Data Protection Officer oversees compliance. In India the Digital Personal Data Protection Act, 2023 and its Rules apply [confirm the current requirement]; elsewhere applicable law in each jurisdiction where the Organisation operates applies.

Privacy notices, consent records, request handling, impact assessments, processor agreements and breach notification run through documented procedures. Privacy is built into new systems before personal data is first collected. Staff handle personal data only for the purpose it was collected.

• A record of processing activities listing purpose, data categories, lawful basis, recipients, location and retention must be maintained and reviewed every [12 months].
• A privacy impact assessment must be completed before new high-risk or large-scale processing starts.
• A data subject request must be acknowledged within [3 working days] and completed within the period required by law, [30 days] by default.
• A processor may handle personal data only under a written agreement.
• A personal data breach must be reported to the Data Protection Officer within [2 hours] of discovery.

Implemented through the Data Protection and Privacy Policy, the Data Protection and Privacy Procedure, the Data Protection Act Compliance Procedure and the Data Governance Policy. Evidence is the processing record, impact assessments and the request log.

8.35 A.5.35 Independent review of information security

The Organisation's approach to information security, covering people, process and technology, is reviewed by someone independent of those who run it, at planned intervals and after significant change. Independence comes from an internal audit function outside the ISMS team, a qualified external auditor or a peer reviewer from another function.

Reviews test design and operating effectiveness against the policy, the Statement of Applicability and the risk treatment plan. Findings go to top management, and none is closed without a corrective plan the reviewer accepts. Routine checking by managers is a different control, set out next.

• The steering committee must approve an audit programme each year, and every in-scope area must be audited at least once every [12 months].
• Auditors must be independent of the area they audit, competent in the method, and never review their own work.
• An independent technical test of exposed systems must be run at least every [12 months].
• A major finding must have a corrective action due within [30 days] and a minor finding within [90 days].
• The audit report must reach top management within [10 working days] of the closing meeting.

Implemented through the Information Security Monitoring and Compliance Policy, the ISMS Compliance Scheduled Activities Plan, the Vulnerability Assessment and Penetration Testing Procedure and the Cyber Compliance Plan. Evidence is the audit programme, audit reports and the corrective action tracker.

8.36 A.5.36 Compliance with policies, rules and standards for information security

Managers and control owners routinely check that work in their area follows policies, standards and procedures, and report the result. Checks are built into daily operations through automated configuration scans, access reviews, log reviews and sampled records, and are backed by periodic self-assessment. The security team tests technical compliance against hardening baselines.

A failure is recorded as a nonconformity, the root cause is found, and corrective action is taken. Where the cause is a rule that cannot be followed, the rule is changed through exception or review. Results are reported openly, and good practice found in one team is shared with others.

• Each control must have an owner, a check method, a frequency and an evidence location in the compliance calendar.
• Control owners must complete a self-assessment every [6 months], and the ISMS team must verify a sample.
• Configuration compliance scans must run at least [weekly] on production systems.
• Nonconformities overdue by [30 days] must be reported to the steering committee.
• Compliance indicators must be reported [monthly] to the steering committee.

Implemented through the Information Security Monitoring and Compliance Policy, the ISMS Compliance Scheduled Activities Plan, the Secure Configuration Policy and the Cyber Compliance Plan. Evidence is the compliance calendar, self-assessment returns and scan reports.

8.37 A.5.37 Documented operating procedures

Operating procedures for information processing facilities are documented, current and available to everyone who needs them. They cover start-up and shutdown, backup, monitoring, maintenance, media handling, change, incident escalation and restart after failure. A procedure states its purpose, owner, prerequisites, steps, expected results, rollback and contacts.

Another person tests a procedure before release. Knowledge held by one person is a risk, so critical procedures have trained deputies. Procedures are written for a competent person who has not done the task before, in plain steps with expected results, so that a deputy can follow them under pressure. Out-of-date copies are removed from circulation.

• Every production system must have a runbook covering start-up, shutdown, backup, restore, monitoring, escalation and rollback.
• A runbook must be reviewed every [12 months] and after any change to the system.
• A procedure must be tested by a walkthrough by someone other than its author before approval.
• An offline copy of each critical procedure must be available when the system is down.
• A change to a procedure must follow document control and be communicated to affected staff within [5 working days].

Implemented through the Documents and Records Management Procedure, the Communications and Operations Security Policy, the Change Management Policy and Procedure and the BCP and DR Procedure. Evidence is the runbook library, walkthrough records and review dates.

9. People controls

People controls follow a person through the relationship with the Organisation: before joining, while working, when changing role and after leaving. HR owns the lifecycle and the line manager is accountable for each person in it, with IT Security setting the security content. The controls below apply to employees, contractors, interns and agency workers alike, and detail sits in the HR Security Policy.

9.1 A.6.1 Screening

Every employee, contractor and agency worker must be screened before receiving access to Organisation information or systems. HR owns the process, and the hiring manager and the Head of IT Security agree the screening tier for each role according to the data and privileges it will hold.

Checks are made only with the individual's written consent and on a lawful basis. Results are kept in a restricted file, and an adverse result goes to the Head of HR for a documented decision rather than to the hiring manager. Candidates are told in advance what will be checked.

• Identity, address and right-to-work documents must be verified against originals before the start date.
• Roles with privileged access or access to Restricted information must also pass [criminal record, credit and directorship] checks before access is provisioned.
• Qualifications and the last [two] employers must be verified with the issuing body or employer, not only from the candidate's copies.
• Agency and contractor suppliers must evidence equivalent screening within [5 working days] of onboarding, or the Organisation performs it.
• Staff must be re-screened every [3 years] and on promotion into a higher screening tier.

Implemented through the HR Security Policy and the HR Security Procedure, which define the screening tiers and the consent form. Evidence is the screening checklist in each personnel file and a monthly HR report of joiners whose checks were still open at their start date, which must be [zero] for privileged roles.

9.2 A.6.2 Terms and conditions of employment

Employment and engagement contracts must state the information security duties of the individual and of the Organisation. No access is granted until the person has signed the contract and the Acceptable Usage Policy acknowledgement.

Terms apply equally to permanent staff, fixed-term staff, interns and contractors, and HR holds the signed copies. Where a duty continues after the engagement ends, the contract says for how long, so that the obligation is never left to inference. Where a term is later varied, HR records the change and the person confirms it in writing, so the Organisation can show which version applied on any given date.

• The contract must be signed by both parties before the first day on which access is provisioned.
• Every contract must include confidentiality, intellectual property assignment, acceptable use, data protection and the consequence of breach.
• Contractor and agency agreements must flow the same duties down to the individuals who do the work.
• Staff must re-acknowledge the Acceptable Usage Policy every [12 months] and whenever its terms change materially.
• Contract templates must be reviewed by legal counsel at least every [24 months].

Implemented through the HR Security Policy, the HR Security Procedure and the Acceptable Usage Policy. Evidence is the signed contract and acknowledgement record per person, and an access provisioning log showing that no account was activated before the signature date.

9.3 A.6.3 Information security awareness, education and training

All personnel must understand the information security rules that apply to them and how to apply them in their daily work. HR runs the awareness programme and the Head of IT Security sets its content, using the risk register and recent incidents to choose topics.

Training is mandatory and tracked. Generic awareness is supplemented by role-based modules for people whose work creates specific risks, and effectiveness is measured by behaviour such as reporting rates, not by attendance alone. Managers release staff for training during working hours and treat completion as part of performance objectives.

• New joiners must complete induction security training within [5 working days] of starting and before access to Confidential data.
• All personnel must complete refresher training every [12 months] and at least [95%] must complete assigned modules within [30 days] of assignment.
• Developers, system administrators and staff handling personal data must complete role-based modules every [12 months].
• Phishing simulations must run [quarterly]; a person who fails [3] in [12 months] receives targeted coaching from IT Security.
• Accounts of personnel more than [60 days] overdue on mandatory training must be escalated to their director for action.

Implemented through the HR Security Policy, the Acceptable Usage Policy and the Employee AI Usage Policy. Evidence is the training platform's completion report, simulation results trended by quarter, and the annual programme review presented to the steering committee.

9.4 A.6.4 Disciplinary process

The Organisation operates a formal, documented disciplinary process for personnel who commit an information security breach. It is applied consistently, proportionately to the seriousness of the breach and its intent, and with the same fairness regardless of seniority.

HR runs the process and IT Security supplies technical evidence. The process is separate from incident response, so that technical containment is never delayed by an HR decision. Personnel who report their own mistakes promptly are treated more favourably than those who conceal them. Outcomes are recorded confidentially and shared only with those who need to act on them.

• An allegation must be logged by HR within [2 working days] and the investigation concluded within [15 working days] unless the Head of HR extends it in writing.
• The individual must be told of the allegation, given access to the evidence relied on and allowed to respond before a decision is taken.
• Sanctions must follow the published scale, from [recorded warning] up to [termination and referral to authorities], and be approved by the Head of HR.
• Retaliation against anyone who reports a breach in good faith is itself a disciplinary matter.
• For contractors, breaches must be handled through the supplier agreement, with the supplier notified within [5 working days].

Implemented through the HR Security Policy, the HR Security Procedure and the Information Security Incident Management Policy. Evidence is the confidential case register showing dates, outcome and sanction, reviewed [annually] for consistency by the Head of HR and the Head of IT Security.

9.5 A.6.5 Responsibilities after termination or change of employment

Information security duties do not end when a person leaves or moves role. HR and the line manager are accountable for ensuring that leavers and movers return assets, are reminded in writing of continuing confidentiality duties, and lose access they no longer need.

This control covers the people-side obligations and the leaver event. The technical review of entitlements, which also happens on every role change, is governed by the Access Control Policy under A.5.18. Line managers confirm in writing on the last working day that handover of information and responsibilities is complete. Contractors are handled identically through their supplier.

• Access of a leaver must be removed by [the end of the last working day], and immediately at notification for involuntary exits.
• All assets, badges, tokens and Organisation papers must be returned and checked against the asset register before final pay is released.
• Movers must have prior access reviewed within [5 working days] and entitlements of the old role removed.
• The leaver must sign an exit acknowledgement restating confidentiality obligations, which continue for [24 months] and indefinitely for trade secrets and personal data.
• Leavers' mailboxes must be redirected to the manager for [30 days] and then archived under the retention schedule.

Implemented through the HR Security Procedure, the User Access Management Procedure and the Asset Management Procedure. Evidence is the signed leaver checklist and a monthly reconciliation of HR leavers against active accounts, with any residual account explained.

9.6 A.6.6 Confidentiality or non-disclosure agreements

A written confidentiality or non-disclosure agreement must be in place before Confidential or Restricted information is shared with anyone outside the Organisation, and with employees whose contract does not already carry equivalent terms. Legal counsel owns the templates.

The agreement states precisely what is protected, for how long and for what purpose. Business owners are accountable for requesting it before disclosure begins, not after; verbal assurances are not a substitute. Agreements with suppliers are made alongside the commercial contract, and the business owner confirms the correct template was used. Staff are reminded at induction that confidentiality also covers information received from customers.

• Templates for mutual and one-way agreements must be approved by legal counsel and reviewed every [24 months].
• Each agreement must define the protected information, permitted use, duration of [3 years] (indefinite for trade secrets and personal data), return or destruction on request and the remedies available.
• No Confidential information may be released until the agreement is signed by an authorised signatory.
• Every agreement must be recorded in the NDA register with counterparty, owner, start and expiry dates, and expiries reviewed [quarterly].
• Agreements must preserve lawful whistleblowing and disclosures required by authorities.

Implemented through the HR Security Policy, the Supplier Relationship Management Policy and the Information Classification and Handling Policy. Evidence is the NDA register and a sample of [10] data-sharing events per quarter checked for an agreement dated before the first disclosure.

9.7 A.6.7 Remote working

Personnel may work remotely only on Organisation-managed or approved devices, over protected connections, and in places where information cannot be seen or overheard. The line manager approves remote working and IT Security maintains the technical baseline.

Remote work does not lower the classification of the information handled. The behaviour expected of the person is set here; the hardening of the devices themselves is covered under A.8.1 and A.7.9. Managers decide whether a role suits remote work, taking into account the information handled, and may withdraw approval if the conditions are not met. The same rules apply when working from a client site.

• Remote devices must be enrolled in device management, with full-disk encryption, endpoint protection and automatic screen lock after [5 minutes].
• Access to Organisation systems must use multi-factor authentication and the [secure access gateway]; public Wi-Fi may be used only through that gateway.
• Confidential information must not be printed at home, and screens must not be visible to household members or the public.
• Working from outside [India] for more than [14 days] requires prior written approval from the line manager and IT Security.
• A lost device or suspected compromise must be reported within [1 hour] of discovery.

Implemented through the Mobile Device and Teleworking Policy and the Mobile Device Management Procedure. Evidence is the device management compliance dashboard, which must show at least [98%] of remote devices compliant, and the register of approved remote workers.

9.8 A.6.8 Information security event reporting

Every person who works for the Organisation must report a suspected or observed information security event promptly through the single reporting channel, without first trying to investigate or fix it. Reporting in good faith is never grounds for discipline.

The service desk records each report and passes security events to the incident manager. Events that may be reportable cyber incidents must reach the incident manager early enough to meet the CERT-In Directions of 28 April 2022, which require reporting within 6 hours of noticing [confirm the current requirement]. The channel is available at all hours.

• Personnel must report within [1 hour] of noticing anything suspicious, such as phishing, lost devices, unauthorised access, tailgating or unexpected data exposure.
• The reporting channel is [the security mailbox, a hotline and a one-click email report button], and its details must be displayed in induction material and on intranet pages.
• The service desk must log each report and acknowledge the reporter within [15 minutes] during business hours.
• Reporters must receive an outcome message within [5 working days], so that reporting is seen to matter.
• Weaknesses, near misses and policy breaches by others must also be reported, and may be done anonymously.

Implemented through the Information Security Incident Management Policy and the Incident Management Procedure. Evidence is the event register, the time between detection and report for each event, and the reporting rate per hundred staff trended each quarter.

10. Physical controls

Physical controls protect premises, equipment and media. The Organisation divides its premises into four zones, from Zone 0 (public) to Zone 3 (restricted), and each control below is applied according to the zone concerned. The Facilities Manager is accountable for the premises, IT Operations for equipment, and the Head of IT Security for the overall standard.

10.1 A.7.1 Physical security perimeters

Areas that hold or process information must be enclosed by defined physical perimeters, with strength proportionate to what is protected. The Facilities Manager owns the perimeter definitions, and the Head of IT Security approves the zone given to each area.

The Organisation uses four zones, shown below. Floor plans mark every zone boundary and are redrawn whenever a layout changes. Controls are chosen from the risk assessment: stronger boundaries for Zone 3, lighter for Zone 1, so that effort follows the value of what is inside. Boundaries owned by a landlord remain the Organisation's responsibility to verify.

• Zone 2 and Zone 3 walls must run slab to slab, so that ceiling voids and raised floors cannot be used to bypass a door.
• Doors and windows in Zones 1 to 3 must be lockable, and external doors must be alarmed.
• Fire exits must open outward, be alarmed and give no external handle.
• A security assessment must be completed before any new site or floor is occupied, and perimeter gaps checked after every layout change.
• In shared buildings the landlord's perimeter duties must be written into the lease or service agreement.

Implemented through the Physical and Environmental Controls Policy and the Physical and Environmental Security Procedure. Evidence is the zone floor plans, the annual perimeter inspection report and the closed-out findings list.

10.2 A.7.2 Physical entry

Only authorised people may enter Organisation premises, and entry points must be controlled and recorded. Facilities issues badges against HR records, and receptionists enforce visitor handling at the entrance.

Visitors, delivery staff and engineers are admitted only for a stated purpose, are escorted outside Zone 0 and are signed out when they leave. Where this control concerns how people behave inside restricted areas, see A.7.6. Badge access follows the zone model, so a badge opens only the zones the holder's role needs. Cards are personal and must never be lent, and receptionists refuse entry when a visitor cannot be verified.

• Badges must be issued only on an HR-approved request and disabled on the leaver's last day or within [1 hour] of a loss report.
• Visitors must show photo identification, wear a visitor badge, be met by the host and be signed out; unreturned badges must be reported to Facilities.
• Entry logs for Zones 2 and 3 must be kept for [12 months], and Zone 3 access lists reviewed [quarterly] by the room owner.
• Deliveries must be received in Zone 0 and not carried into other zones unaccompanied.
• Personnel must challenge or report tailgating; piggy-backing on another badge is a reportable event.

Implemented through the Physical and Environmental Security Procedure and the Access Control Policy. Evidence is the visitor register, badge issue and revocation log, the quarterly Zone 3 access review sign-off and results of unannounced tailgating tests.

10.3 A.7.3 Securing offices, rooms and facilities

Offices, rooms and facilities that hold sensitive information or equipment must be designed and arranged to prevent unauthorised observation, access and tampering. The Facilities Manager chooses locations and layouts with IT Security, and room owners are accountable for day-to-day compliance.

Sensitive rooms are not advertised: signage, directories and internal phone lists must not reveal where information processing takes place. Keys, codes and combinations are treated as controlled assets. Room owners are named on the key register and inspect their rooms [weekly], reporting damaged locks and blind spots to Facilities within [1 working day]. Changes to room use, such as converting a store into a meeting room, are approved by IT Security first.

• Server, network and archive rooms must be locked at all times and carry no signage that identifies their contents.
• Keys and mechanical codes must be held in a key register, and codes changed every [6 months] and when any holder leaves.
• Meeting rooms used for confidential discussion must have whiteboards erased and materials removed after each session.
• Sensitive screens and papers must not be visible from windows, corridors or glazed doors.
• Unoccupied rooms, storage areas and risers must be locked, with a daily lock check recorded by Facilities.

Implemented through the Physical and Environmental Controls Policy and the Physical and Environmental Security Procedure. Evidence is the key and code register, daily lock-check sheets and the floor-walk findings from the [quarterly] physical security inspection.

10.4 A.7.4 Physical security monitoring

Premises must be monitored continuously for unauthorised physical access, using detection technology and trained people. The Facilities Manager owns the monitoring systems; the security supervisor or monitoring provider responds to alerts.

Monitoring serves protection, not surveillance of staff. It covers entrances, loading areas and Zone 3, and avoids private areas such as toilets and changing rooms. Footage is personal data and is handled under the Data Protection and Privacy Policy. Alerts are triaged by a trained responder who decides whether to dispatch security, call the police or escalate to the incident manager. Monitoring records are treated as evidence and protected from alteration.

• Cameras must cover every external entrance, Zone 3 door, loading bay and car park access, with clocks synchronised to a trusted source.
• Recordings must be retained for [90 days] and viewed or exported only with written approval of the Head of IT Security or Head of HR.
• Intruder and door-forced alarms must be tested [monthly], and alarm response must start within [15 minutes], 24 hours a day.
• Camera and recorder health must be checked [weekly], and any outage over [24 hours] treated as a security event.
• Notices must tell people that monitoring is in operation.

Implemented through the Physical and Environmental Controls Policy, the Physical and Environmental Security Procedure and the Data Protection and Privacy Policy. Evidence is test records of alarms, response-time reports, the weekly camera health sheet and the export approvals log.

10.5 A.7.5 Protecting against physical and environmental threats

The Organisation must assess physical and environmental threats to each site, including fire, flood, earthquake, extreme heat, lightning, power surge, theft and civil disturbance, and put protection in place before critical equipment is installed.

The Facilities Manager carries out the site risk assessment with IT Security, and the findings feed the risk register and continuity plans. Protection is layered so that one failure does not take down a site. Controls are chosen to be passive where possible, such as raised equipment, fire-rated walls and drainage, because passive protection still works when staff and power are not available.

• A site threat assessment must be completed before occupancy and reviewed every [12 months] and after any significant incident.
• Zone 3 rooms must have smoke detection and a gas-based suppression system, and water-leak sensors under raised floors and above racks.
• Fire extinguishers and detectors must be inspected [annually] by a competent provider, and evacuation drills held at least [twice] a year.
• Critical equipment must not be sited in basements, flood-prone areas or beneath water pipes unless a documented mitigation exists.
• Temperature and humidity sensors in server rooms must alert the on-call engineer when readings leave [18 to 27 degrees Celsius].

Implemented through the Physical and Environmental Controls Policy, the Physical and Environmental Security Procedure and the Information Security Aspects of Business Continuity Policy. Evidence is the site threat assessment, inspection certificates, drill reports and the sensor alert log.

10.6 A.7.6 Working in secure areas

People who work inside secure areas must follow rules that limit what they see, bring in and do. These rules apply to employees as well as contractors, and the owner of each secure area is accountable for enforcing them.

Entry (A.7.2) decides who gets in; this control governs behaviour once inside. Work in Zone 3 is done on a need-to-know basis, and third-party engineers are never left alone. The rules are short, posted at the door and acknowledged on entry. Work that does not need to happen in a secure area is moved elsewhere, and supervisors check that logged visits match authorised work orders.

• Personnel in Zone 3 must have a recorded business reason, and entry for each visit must be logged.
• Contractors and maintenance engineers must be escorted at all times in Zone 3 by an authorised employee.
• Cameras, recording devices and personal phones must not be used in Zone 3 unless the room owner approves for [the stated task].
• Vacant secure areas must be locked and inspected every [24 hours].
• Rules for working in each secure area must be posted at the entrance and acknowledged by every person admitted.

Implemented through the Physical and Environmental Controls Policy and the Physical and Environmental Security Procedure. Evidence is the Zone 3 visit log, escort sign-off, rule acknowledgement records and findings of random observation checks by IT Security.

10.7 A.7.7 Clear desk and clear screen

Papers, removable media and screens must not expose information to anyone without a need to see it. Every person is responsible for their own workspace, and managers are accountable for their teams' compliance.

The rule is simple: when you leave, lock the screen; at the end of the day, clear the desk. Confidential material is locked away, printed output is collected immediately and nothing sensitive stays on a whiteboard. Managers lead by example, and the rule applies equally to executives and shared desks. Screens in open-plan areas are fitted with privacy filters where [Restricted] information is regularly displayed.

• Screens must lock automatically after [5 minutes] of inactivity and manually whenever the user leaves the desk.
• At the end of each working day, Confidential and Restricted papers and removable media must be locked in a cabinet or drawer.
• Print jobs must be released at the printer with a badge or code, and uncollected output destroyed after [24 hours].
• Passwords and access codes must never be written on notes or left near the workstation.
• Facilities and IT Security must run unannounced spot checks [monthly] and report the pass rate to managers.

Implemented through the Acceptable Usage Policy, the Information Classification and Handling Policy and the Physical and Environmental Controls Policy. Evidence is the monthly spot-check results, which should show a pass rate of at least [95%], and tracked follow-up on repeat failures.

10.8 A.7.8 Equipment siting and protection

Equipment must be sited and protected to reduce the risk of environmental hazards, unauthorised access and opportunistic damage. IT Operations chooses the location of servers and network equipment in consultation with Facilities.

Equipment that processes Confidential information is not placed where passers-by can see or reach it. Shared devices such as printers and meeting-room systems are treated as part of the network and located in controlled areas. Equipment is sited so that engineers can reach it for maintenance but visitors cannot, and cable and power routes are planned at the same time. Locations of critical equipment are reviewed whenever the room layout or heat load changes.

• Servers and network devices must be installed in locked racks within Zone 2 or 3, away from windows, water pipes and heat sources.
• Screens and printers handling Confidential data must be positioned so they cannot be viewed from public or shared areas.
• Eating, drinking and smoking must be prohibited in equipment rooms, with a clear sign at each entrance.
• Surge protection must be fitted to all critical equipment, and lightning protection to external communication lines.
• Equipment locations must be recorded in the asset register and rechecked at each [annual] asset verification.

Implemented through the Physical and Environmental Controls Policy, the IT Asset Management Policy and the Asset Management Procedure. Evidence is the asset register location field, the rack layout drawings and the results of the annual verification walk.

10.9 A.7.9 Security of assets off-premises

Assets taken outside Organisation premises must be recorded and protected as if the risks of travel, home and public places were real, because they are. The asset owner is accountable, and IT Operations enforces the technical protection.

This control covers the device and its physical custody; the working practices of people at home are covered by A.6.7. Removal of equipment, media or papers requires authority from the line manager. The borrower is personally responsible for the asset while it is away and must return it in the condition recorded. Loss is reported at once, because early reporting is what makes remote wipe effective.

• Assets leaving premises must be recorded in the asset register with the borrower, purpose and expected return date.
• Laptops and mobile devices must have full-disk encryption and remote-wipe capability, and be wiped within [24 hours] of confirmed loss.
• Equipment must never be left unattended in vehicles, public places or checked baggage; travel with it as hand luggage.
• Devices must not be connected to shared or public computers, and Confidential papers must not be left in hotel rooms.
• Staff travelling to [high-risk locations] must use clean loaner devices approved by IT Security.

Implemented through the IT Asset Management Policy, the Asset Management Procedure and the Mobile Device Management Procedure. Evidence is the movement log, encryption compliance reports and the record of loss reports with their time-to-wipe.

10.10 A.7.10 Storage media

Storage media must be managed throughout their life cycle, from acquisition, use and transport to disposal, in line with the classification of the information on them. Removable media are blocked by default because they are the easiest route for data loss.

IT Operations owns the media register and the technical blocking, and business owners must justify any exception. Media containing Confidential information are encrypted whatever their location, and their final destruction follows A.7.14. Personal drives, phones and cloud storage are not approved media for Organisation data, and use of approved media is logged where the technology allows.

• Removable media ports must be disabled by default, and use approved only for [a stated purpose] and for [a limited period].
• Approved media must be encrypted, labelled with the classification and entered in the media register.
• Media in transit must be sent sealed and tracked by an approved courier, with receipt confirmed within [2 working days].
• Media not in use must be kept in locked storage, and backup media in a separate fire-resistant location.
• Unlabelled or unknown media found on premises must not be connected and must be handed to IT Security.

Implemented through the Information Classification and Handling Policy, the Backup and Restoration Policy and the Asset Management Procedure. Evidence is the media register, exception approvals and a quarterly reconciliation of registered media against physical stock.

10.11 A.7.11 Supporting utilities

Facilities that carry power, cooling, communications and water to information-processing areas must be protected against failure and disruption. The Facilities Manager is accountable, and each utility has a named service owner.

Protection is sized to the recovery objectives in the business continuity plans. Where the Organisation relies on a landlord or data centre provider, the same expectations are written into the service agreement. Single points of failure are identified during the site assessment and either removed or recorded as accepted risks with the owner's signature. Utility maintenance is scheduled outside critical business periods and done only by qualified contractors.

• Utilities supporting critical systems must have redundancy equal to or better than [N+1].
• Emergency power and cooling arrangements must be load-tested at least [quarterly], with results recorded.
• Emergency shut-off controls must be located near exits, clearly labelled and protected from accidental use.
• Utility faults must be monitored and alerted to the on-call engineer within [5 minutes] of detection.

Implemented through the Physical and Environmental Controls Policy, the Physical and Environmental Security Procedure and the Information Security Aspects of Business Continuity Policy. Evidence is the test log of each utility, maintenance contracts and downtime reports.

10.12 A.7.12 Cabling security

Cables that carry power, data or telecommunications services must be protected from interception, interference and damage. IT Operations owns the cabling documentation, and Facilities controls physical access to conduits, risers and cabinets.

Cabling is documented and labelled so that an unauthorised connection is visible, and all changes follow the change process. Cabling carries data wherever it passes, so it is protected as part of the network even where it runs through shared building risers or ceilings. Tampering is most likely at accessible patch points, which is why they are locked and why live ports are compared against the documented connection list. Cables leaving Organisation control are routed in sealed conduit.

• Power and network cables must be segregated by at least [30 cm] or by shielded conduit to prevent interference.
• Patch panels, switches and cable cabinets must be locked, with keys controlled by IT Operations.
• Cables must be labelled at both ends and recorded in the cabling register, which is updated within [5 working days] of any change.
• Unused network ports must be disabled or left unpatched, and wall ports in public areas must not be live.
• Cabling in Zone 3 and between buildings must be inspected [annually] for tampering, taps or damage.

Implemented through the Physical and Environmental Controls Policy, the Physical and Environmental Security Procedure and the Communications and Operations Security Policy. Evidence is the cabling register, the annual inspection report and the monthly list of live ports compared against documented connections.

10.13 A.7.13 Equipment maintenance

Equipment must be maintained correctly so that its availability and integrity are preserved. IT Operations schedules maintenance, and the service owner approves each maintenance window through the change process.

Only authorised, identified engineers may maintain equipment. Anything leaving the site for repair must be treated as a disclosure risk, and remote maintenance is permitted only under supervision. Maintenance is also an opportunity for attack, because engineers often hold elevated access and bring their own tools. The Organisation therefore treats every maintenance visit, in person or remote, as controlled access to the zone and system concerned, and withdraws that access when the work ends.

• Equipment must be maintained at the supplier's recommended intervals, with a maintenance schedule in the asset register.
• Maintenance engineers must be identified on arrival, escorted in secure areas and have each visit logged with work performed.
• Storage must be removed, encrypted or wiped before equipment goes off-site, unless the repair contract has an approved confidentiality clause.
• Remote maintenance sessions must be requested, approved, supervised and logged, and closed when done.
• Equipment must be tested and inspected after maintenance and before returning to service.

Implemented through the IT Asset Management Policy, the Asset Management Procedure and the Change Management Policy and Procedure. Evidence is the maintenance log, change records for each window and the post-maintenance test sign-off.

10.14 A.7.14 Secure disposal or re-use of equipment

Equipment containing storage media must be checked and its data securely removed, or the media destroyed, before disposal or re-use. IT Operations is accountable, and no asset may leave the Organisation without a completed disposal record.

This control covers whole equipment such as laptops, servers and printers. Loose media in circulation is handled under A.7.10. Sanitisation method follows the highest classification the device ever held. Disposal is the last point at which data can leak, so nothing is discarded, sold, donated or returned to a lessor on the strength of a verbal assurance. Exceptions are approved by the Head of IT Security in writing.

• Every device must be checked for storage media, including in printers and network equipment, and the check recorded.
• Data must be cleared using an approved method, such as cryptographic erase or [multi-pass overwrite], before re-use inside the Organisation.
• Failed or end-of-life media holding Confidential data must be physically destroyed, witnessed by IT Security.
• Third-party disposal vendors must provide a certificate of destruction within [10 working days] of collection.
• Asset tags and licences must be removed, and the asset register updated, before the item leaves the site.

Implemented through the Asset Disposal Process, the IT Asset Management Policy and the Asset Management Procedure. Evidence is the disposal record per asset, the vendor certificate and a quarterly reconciliation of disposed assets against the asset register.

11. Technological controls

The Organisation applies the following technological controls to every system that stores, processes or transmits its information or its customers' information, whether the system is run in-house, by a supplier or in the cloud. Each control states the policy, the testable requirements that follow from it, and the library documents that carry the detail. Values in square brackets are defaults that the Organisation confirms or replaces at its next ISMS review.

11.1 A.8.1 User endpoint devices

The Organisation protects information held on, or reachable from, laptops, desktops, tablets and phones by treating every endpoint as a managed asset with a named owner. Only devices enrolled in the device management tool may open a session to Organisation systems, whether the device is issued by the Organisation or is a personal device approved for limited use.

The Head of IT Security is accountable for the endpoint standard. The IT operations team enrols, configures and retires devices. Each user is responsible for the physical care of the device and for reporting its loss without delay.

• Every endpoint must be enrolled in the device management tool before first use and must apply the approved hardening baseline.
• Full-disk encryption must be enabled and verified, and the screen must lock after [5 minutes] of inactivity.
• Endpoint protection must report to its console at least every [24 hours]; a device silent for [14 days] must lose access until it is checked.
• A lost or stolen device must be reported within [2 hours] of discovery and remotely locked within [1 hour] of the report.
• Local administrator rights must not be granted by default; an exception needs approval from the line manager and IT security and expires after [90 days].

Implemented through: the Mobile Device and Teleworking Policy, the Mobile Device Management Procedure, the Secure Configuration Policy and the Acceptable Usage Policy. The monthly enrolment and compliance report from the device management tool, the loss register and remote wipe confirmations show that the control works.

11.2 A.8.2 Privileged access rights

Privileged access rights let a person change security settings, read data outside their role or administer a platform. The Organisation therefore grants them sparingly, keeps them apart from everyday accounts and withdraws them when the task ends. This control covers the elevated accounts themselves; the ordinary grant, review and removal of business access is governed by A.5.18 Access rights.

The system owner approves each privileged role, the Head of IT Security reviews the complete list, and every administrator answers for each action taken under their elevated identity. Break-glass credentials are held sealed, and the Organisation counts every use as a security event until reviewed.

• Administrators must use a separate, named administrative account for privileged work and a standard account for email and browsing.
• Shared or generic administrative accounts must not be used, except sealed break-glass accounts whose every use triggers a review within [24 hours].
• Multi-factor authentication must be enforced on every privileged login, and elevation to production must be time-limited to [8 hours].
• Privileged sessions on critical systems must be logged, or recorded where the platform supports it, and kept for [12 months].
• The privileged account list must be reviewed every [3 months], and an account unused for [45 days] must be disabled.

Implemented through: the Access Control Policy, the User Access Management Procedure and the Logging and Monitoring Policy. The signed quarterly privileged account review, the break-glass usage log and the session records are the evidence.

11.3 A.8.3 Information access restriction

Access to information inside systems is limited to what each role needs to do its work. A.5.15 Access control sets the rules; this control is the technical enforcement of those rules inside applications, databases, file stores and collaboration tools, so that a permission granted on paper is actually the permission a system applies.

Data owners define who may see what. System owners configure it, and IT security tests that the restriction holds. Where a system cannot enforce a restriction itself, the data must be moved to one that can. Restrictions are judged by what a user can actually reach, so contractors and service accounts are held to the same standard as staff.

• Systems must apply default-deny: a user sees nothing until a role or group grants it.
• Permissions must be assigned to roles or groups and not to individuals, except for documented one-off cases that expire in [30 days].
• Direct access to production databases must need approval from the data owner, use a named account and be logged in full.
• Downloading, exporting or bulk printing of Restricted information must be limited to the roles listed in the system's access matrix.
• Access restrictions must be tested at each major release and at least every [12 months] for systems holding Restricted information.

Implemented through: the Access Control Policy, the Information Classification and Handling Policy, the Data Governance Policy and the User Access Management Procedure. Role matrices, permission test results and the annual entitlement report show that restrictions are in force.

11.4 A.8.4 Access to source code

Source code, build scripts, infrastructure definitions and the artefacts built from them are valuable and, if altered, a route to compromise every customer that runs the result. Access to them is therefore controlled more tightly than ordinary documents and every change leaves a trail.

Engineering managers decide who may read or change each repository. The code platform administrator enforces branch protection, and the Head of IT Security reviews repository access. Developers must never copy code to personal storage or unapproved services. Open source or third-party code brought into a repository is subject to the same controls as code written by the Organisation.

• Repositories must be held only on the approved code platform, with access granted by team and reviewed every [3 months].
• Write access to the main branch must be blocked; every change must pass review by at least [one] other qualified person.
• Credentials, keys and tokens must not be committed; secret scanning must run on every push and a detected secret must be revoked within [4 hours].
• Release builds must be produced by the build pipeline from tagged commits, never from a developer's machine.
• Access for a leaver or a contractor must be removed from the code platform on the last working day.

Implemented through: the Systems Acquisition, Development and Maintenance Policy, the System Development and Maintenance Procedure and the Access Control Policy. Repository access reports, branch protection settings and secret scanning results are the evidence.

11.5 A.8.5 Secure authentication

The Organisation lets a person or service into a system only after the identity is proven by a method that matches the risk of what is being opened. A.5.17 Authentication information governs how secrets are issued and kept; this control governs how a login attempt is challenged, limited and ended.

The Head of IT Security sets the authentication standard. System owners must apply it, and any system that cannot meet it must be shielded behind a gateway that can. Single sign-on is preferred so that one strong control covers many systems. Service and application accounts that cannot use a second factor must use certificate or key-based authentication and be bound to named hosts.

• Multi-factor authentication must be required for remote access, administrative access, email and every system holding Confidential or Restricted information.
• Passwords must be at least [14] characters; screening against known breached passwords must be applied; periodic forced expiry must not be used without cause.
• An account must be locked for [15 minutes] after [5] failed attempts, and the failure must be logged and alerted.
• Sessions must end after [15 minutes] of inactivity for sensitive applications and after [12 hours] at most for others.
• Login screens must not disclose whether a username exists, and must not reveal system or version details.

Implemented through: the Access Control Policy, the User Access Management Procedure and the Secure Configuration Policy. The identity provider configuration export, the authentication coverage report and the lockout alerts are the evidence.

11.6 A.8.6 Capacity management

The Organisation plans the processing, storage, network and people capacity that its services need, so that growth or a spike never forces a shortcut that weakens security or availability. Capacity is a security matter because an exhausted system drops logs, fails open or becomes an easy target for denial of service.

Service owners monitor utilisation and forecast demand. The IT operations team raises capacity requests, and the Head of IT approves spend. Forecasts are reviewed in the management review of the Organisation. Cloud elasticity does not remove the duty: the Organisation sets spending and scaling limits so that growth is deliberate and cost is visible.

• Each production service must have utilisation thresholds defined for processor, memory, storage and bandwidth, with alerts at [80%] and escalation at [90%].
• Log storage must be sized to hold the full retention period at peak volume plus [25%] headroom.
• Service owners must publish a rolling [12-month] demand forecast, updated at least every [6 months].
• Load and stress tests must be run before a major launch and after any change expected to raise demand by more than [30%].
• A capacity alert open for more than [5 business days] without a plan must be escalated to the Head of IT.

Implemented through: the Capacity Management and Planning Procedure, the Communications and Operations Security Policy and the Information Security Aspects of Business Continuity Policy. Utilisation dashboards, forecasts and load test reports show that capacity is managed ahead of need.

11.7 A.8.7 Protection against malware

Malicious software is stopped by layers: prevention on endpoints and servers, filtering of email and web traffic, and trained users who recognise and report suspicious items. No single product is relied upon, and every layer is itself monitored for failure.

The Head of IT Security owns the malware defence standard. The IT operations team deploys and maintains the tools, and the security operations function responds to detections. Users must not disable or bypass protection for any reason. Detection is only useful if it is followed by action, so every alert is assigned an owner and a response time, and unmanaged devices are kept off the corporate network.

• Endpoint detection and response must be installed on every endpoint and server that can run it, with definitions or models updated within [4 hours] of release.
• Email attachments and links must be scanned and detonated or rewritten before delivery, and executable file types must be blocked in transit.
• Removable media must be blocked by default; approved media must be scanned on connection.
• A detection on a user device must lead to network isolation of that device within [1 hour] of the alert.
• Awareness content on phishing and malicious attachments must be completed by every user at least every [12 months].

Implemented through: the Malware Protection Policy, the Acceptable Usage Policy and the Incident Management Procedure. The protection coverage report, detection and isolation records, and phishing simulation results are the evidence.

11.8 A.8.8 Management of technical vulnerabilities

Technical weaknesses in systems, applications and components are found early, ranked by real risk and fixed within set times. The Organisation does not rely on the supplier's severity label alone: exposure to the internet, the sensitivity of the data and known exploitation all raise the priority.

The Head of IT Security owns the vulnerability programme. System owners are accountable for fixing what is found on their systems, and unresolved items past their deadline are reported to the steering committee. Systems that cannot be patched are shielded by compensating controls such as isolation or virtual patching, and the choice is recorded with an end date.

• Internal scans must run at least every [week] and external scans at least every [week] for internet-facing assets; a full penetration test must be done every [12 months].
• Findings must be rated using a consistent scoring method adjusted for exposure and exploitation, and recorded in the ticketing tool.
• Remediation or an approved compensating control must meet the deadlines in the table below, measured from the date the finding is confirmed.
• A vulnerability under active exploitation must be treated as Critical regardless of its published score.
• An exception to a deadline needs risk acceptance from the system owner and the Head of IT Security and expires after [90 days].

Implemented through: the Vulnerability Assessment and Penetration Testing Procedure, the Patch Management Policy, the Patch Management Procedure and the Threat Intelligence Policy. Scan reports, remediation ageing charts and approved exceptions are the evidence.

11.9 A.8.9 Configuration management

Every system has a documented secure baseline, and the Organisation checks that what is running still matches it. Configuration is treated as controlled information: it is held in a repository, changed only through approved change records and compared against the baseline automatically.

The Head of IT Security approves baselines. System owners keep them current, and the IT operations team applies them and investigates drift. Vendor defaults must never remain in service. Cloud and infrastructure-as-code definitions are treated as configuration, so they receive the same review and protection as server settings.

• A hardened baseline must exist for each class of server, network device, cloud service, database and endpoint, and be reviewed every [12 months].
• Default accounts, passwords and sample content must be removed or changed before a system is connected to a network.
• Services, ports and protocols that are not needed must be disabled, and the reason for any that remain must be recorded.
• Configuration drift checks must run at least every [7 days]; a deviation must be corrected or approved within [5 business days].
• Configuration files for infrastructure must be held under version control and changed only through the change process.

Implemented through: the Secure Configuration Policy, the Change Management Policy and Procedure and the IT Asset Management Policy. Baseline documents, drift reports and the configuration repository history are the evidence.

11.10 A.8.10 Information deletion

Information is deleted when the reason for keeping it has ended, and the deletion is complete, not merely hidden. Holding data longer than needed increases the harm of any breach and, for personal data, conflicts with the Digital Personal Data Protection Act, 2023 and its Rules [confirm the current requirement].

Data owners set retention periods. The IT operations team carries out and records deletion, and the data protection officer checks that personal data deletion requests are honoured within the period promised. Deletion is requested by the data owner or follows automatically from the schedule, and it is verified, because assuming it happened is not enough.

• Each category of information must have a retention period and a deletion trigger recorded in the retention schedule.
• Deletion must cover live systems, replicas, archives and test copies, and backups must age out within [35 days] after the live deletion.
• Storage media and cloud volumes must be wiped or cryptographically erased to the standard in the disposal process before reuse or return.
• Suppliers holding Organisation data must delete it within [30 days] of contract end and provide written confirmation.
• A deletion log must record what was deleted, by whom, when and under which schedule entry.

Implemented through: the Information Classification and Handling Policy, the Data Governance Policy, the Asset Disposal Process, the Backup Management and Retention Procedure and the Data Protection and Privacy Procedure. The retention schedule, deletion logs and supplier confirmations are the evidence.

11.11 A.8.11 Data masking

Where a person or process does not need to see the real value of personal or sensitive data, the Organisation masks it. Masking reduces the number of people who handle live identifiers, supports privacy by design and limits damage when a display, report or extract is exposed.

Data owners decide which fields are masked and which roles may unmask them. System owners implement masking at the lowest layer that can enforce it. Masking used to build test data is covered under A.8.33 Test information. Masking is chosen to suit the purpose: display masking for screens, tokenisation for stored identifiers and pseudonymisation for analysis.

• Account numbers, national identifiers, payment card numbers and similar fields must be displayed masked, showing no more than the last [4] characters, unless the role needs the full value.
• Unmasking must be limited to named roles and every unmasking action on Restricted data must be logged.
• Where analytics do not need identity, data must be pseudonymised, and the key or mapping table held separately under tighter access.
• Masking and tokenisation methods must be approved by IT security and reversible methods must use keys managed under the key management process.
• Reports and exports leaving a system must be masked by default.

Implemented through: the Data Protection and Privacy Policy, the Data Governance Policy, the Cryptography Policy and the Data Protection and Privacy Procedure. Masking rules per system, role-based unmasking logs and sample extracts show the control working.

11.12 A.8.12 Data leakage prevention

The Organisation watches the routes by which information leaves its control: email, web uploads, cloud storage, removable media, printing and messaging. Data leakage prevention tools detect and, for the most sensitive information, block unauthorised movement, while allowing the normal flow of work.

The Head of IT Security owns the rules. The security operations function triages alerts, and managers are consulted when a team member is involved. Use of monitoring tools must respect the privacy notice given to staff. Rules protect the information and not the person: they are applied equally to all users, including administrators and executives.

• Detection rules must cover Restricted and Confidential information, personal data patterns and source code on email, web upload, cloud storage and removable media.
• New rules must run in monitor-only mode for [30 days] and be tuned before blocking is enabled.
• Restricted information must be blocked from leaving to personal email, unapproved cloud storage and public generative AI services.
• Alerts must be triaged within [1 business day]; a confirmed leak must be raised as an incident.
• Business exceptions must be approved by the data owner, time-limited to [90 days] and logged.

Implemented through: the Information Classification and Handling Policy, the Acceptable Usage Policy, the Employee AI Usage Policy and the Information Security Incident Management Policy. Rule sets, alert triage records and tuning reviews are the evidence.

11.13 A.8.13 Information backup

Copies of information and systems are taken, protected and tested so that the Organisation can recover to an agreed point after loss, corruption or ransomware. A backup that has never been restored is treated as unproven.

Service owners set the recovery point and recovery time for each service. The IT operations team runs the backups, and the Head of IT Security checks that backup copies are isolated from the accounts that run production. Backups of cloud services and software-as-a-service data are included, because supplier availability does not guarantee recovery of the Organisation's own data.

• Backups must follow the rule of at least [3] copies on [2] different media types with [1] copy held offline or immutable and in a separate location.
• Backup data must be encrypted in transit and at rest, with keys held apart from the backup system's administrators.
• Backup failures must be corrected, or the backup rerun, within [1 business day]; a service with [2] consecutive failures must be escalated.
• A restoration test must be performed for each Tier 1 service every [3 months] and for other services every [12 months], with results recorded.
• Immutable copies must be retained for at least [30 days] and deletion of backup sets must need two approvers.

Implemented through: the Backup and Restoration Policy, the Backup Management and Retention Procedure and the BCP and DR Procedure. Job success reports, restoration test records and retention settings are the evidence.

11.14 A.8.14 Redundancy of information processing facilities

Services whose loss would harm customers or breach commitments are built so that one failed component, host, site or provider does not stop them. The level of redundancy follows the availability target and the cost of downtime, and it is tested rather than assumed.

Architects design redundancy into Tier 1 services. Service owners maintain failover documentation, and the IT operations team runs the failover tests. Redundancy that shares a hidden dependency, such as one power feed or one account, does not count. Redundancy for security tools matters as much as for applications, so monitoring, logging and authentication services are included in the design.

• Each Tier 1 service must have no single point of failure in compute, storage, network path, power and internet connectivity.
• Cloud workloads that serve customers must run across at least [2] availability zones or regions.
• Failover must be tested for each Tier 1 service at least every [6 months] and the measured recovery time recorded.
• Redundant components must be monitored; loss of one side of a pair must be treated as an incident with a repair target of [24 hours].
• Capacity of the surviving component must carry at least [100%] of peak load.

Implemented through: the Information Security Aspects of Business Continuity Policy, the BCP and DR Procedure, the Capacity Management and Planning Procedure and the Cloud Computing Security Policy and Procedure. Failover test reports, architecture diagrams and availability statistics are the evidence.

11.15 A.8.15 Logging

The Organisation records the events needed to reconstruct who did what, where and when on its systems, and protects those records from change. Logs support investigation, accountability and regulatory response. This control concerns producing and keeping logs; A.8.16 Monitoring activities concerns watching them.

Each system owner is accountable for logging on their system. The security operations function operates the central log store and checks that every source is reporting. Log content is classified as Confidential, so reading it needs authorisation, and deletion before the retention period ends is a security event.

• The events in the table below must be logged on every in-scope system, with timestamp, user or service identity, source address, action and outcome.
• ICT logs must be kept for [180 days] within Indian jurisdiction, as the CERT-In Directions of 28 April 2022 provide [confirm the current requirement].
• Logs must be sent to a central store within [5 minutes] and must be write-once for administrators of the source systems.
• Logs must not contain passwords, full card numbers or other secrets; personal data in logs must be kept to what the purpose needs.
• A source that stops reporting for more than [1 hour] must raise an alert.

Implemented through: the Logging and Monitoring Policy, the Logging and Monitoring Procedure and the Information Security Monitoring and Compliance Policy. Log source inventories, completeness checks and retention settings are the evidence.

11.16 A.8.16 Monitoring activities

Networks, systems and applications are watched continuously for behaviour that departs from the normal, so that an attack or misuse is noticed in minutes or hours rather than months. Monitoring turns collected logs into decisions; the production and retention of those logs is in A.8.15 Logging.

The security operations function runs monitoring, reviews alerts and tunes detection rules. Business owners help to define what normal looks like. A confirmed event is handed to the incident process without delay. Findings feed back into prevention: a recurring alert is a prompt to fix its cause rather than to tune the alert away.

• Detection use cases must cover account compromise, privilege misuse, malware, data exfiltration, unauthorised changes and access from unusual locations.
• Alerts must be triaged within [30 minutes] for Critical, [4 hours] for High and [1 business day] for Medium severity.
• Monitoring must run [24 hours a day] for Tier 1 services; other services may be covered during business hours with a documented rationale.
• Detection rules must be reviewed every [6 months] and after every significant incident for gaps and false positives.
• Cyber incidents must be reported within [6 hours] of being noticed where required by the CERT-In Directions of 28 April 2022 [confirm the current requirement].

Implemented through: the Logging and Monitoring Policy, the Logging and Monitoring Procedure, the Incident Management Procedure and the Threat Intelligence Policy. Alert queues, triage timings and detection coverage reviews are the evidence.

11.17 A.8.17 Clock synchronization

Every clock that stamps a record must agree, because investigation, audit trails and transaction ordering depend on events from different systems lining up. The Organisation therefore keeps a small set of authoritative time sources and requires everything else to follow them.

The IT operations team runs the internal time servers and the Head of IT Security reviews the design. System owners must configure each system to use them and must not set time by hand. This matters most for cross-system investigation, evidence that must stand up to challenge and the reporting deadlines that run from the time an incident is noticed.

• At least [2] internal time servers must synchronise to [3 or more] independent, reliable external time sources.
• Servers, network devices, security tools and applications must synchronise only to the internal time servers.
• Records must be stored in UTC; local time may be used only for display.
• Drift of more than [1 second] on a logging source must raise an alert and be corrected within [1 business day].
• Time synchronisation settings must be checked at least every [month] and after any change to a time server.

Implemented through: the Communications and Operations Security Policy, the Secure Configuration Policy and the Logging and Monitoring Procedure. Time server configurations, drift reports and sampled log comparisons are the evidence.

11.18 A.8.18 Use of privileged utility programs

Some utilities can override normal controls: disk and memory editors, database administration consoles, debuggers, remote administration tools, password recovery tools and network scanners. They are kept off general systems and available only to people who need them, for approved tasks. Elevated accounts are covered in A.8.2, and installing software on live systems in A.8.19.

The IT operations team keeps the approved utility list. The Head of IT Security approves additions and checks usage. Where a utility is built into a platform and cannot be removed, its use is restricted by permissions and monitored instead.

• An approved list of privileged utilities must exist, naming the permitted users and the systems on which each may run.
• Utilities not on the list must be removed or blocked on servers and endpoints by application control.
• Each use must need a ticket or change reference, and must be logged with the user, time and system.
• Access to a utility must be granted for a limited period and must be removed when the task is done, within [1 business day].
• Logs of utility use must be reviewed by IT security at least every [month].

Implemented through: the Access Control Policy, the Secure Configuration Policy and the Logging and Monitoring Policy. The approved utility list, application control settings and the monthly usage review are the evidence.

11.19 A.8.19 Installation of software on operational systems

Software is installed on production systems only when it has been approved, tested and recorded. This stops untested or malicious code, unlicensed products and unsupported versions from reaching systems that customers and staff depend on. Standard user installs on endpoints are governed by the Acceptable Usage Policy.

The IT operations team installs production software. The system owner approves the need, and IT security assesses the risk. Developers and ordinary users may not install on production systems. Package managers, scripts and automated deployments are controlled in the same way as manual installs, as they can introduce software just as effectively.

• Only software on the approved software list may be installed on production systems.
• New software and every update must be tested in a non-production environment that mirrors production and signed off before release.
• Every installation must have a change record and a rollback plan that can be carried out within [2 hours].
• Software must be within vendor support; a product nearing end of support must be replaced or risk-accepted at least [6 months] before the date.
• The software inventory must be reconciled with installed software at least every [3 months].

Implemented through: the Change Management Policy and Procedure, the Secure Configuration Policy, the Acceptable Usage Policy and the IT Asset Management Policy. The approved software list, change records and reconciliation reports are the evidence.

11.20 A.8.20 Networks security

The Organisation's networks are designed, operated and watched so that information passing across them is protected and so that connected systems cannot be reached by those who should not reach them. A.8.21 covers services supplied by providers and A.8.22 covers separation into zones; this control covers the network itself.

The network team is responsible for design and operation. The Head of IT Security approves the standards and reviews rule changes that open access from outside. Networks must be assumed hostile, so internal traffic is authenticated and encrypted where it carries Confidential or Restricted data and not only at the edge.

• Firewalls must apply default-deny for inbound and outbound traffic, and every allow rule must carry an owner, purpose and review date.
• Firewall rule sets must be reviewed at least every [6 months] and unused rules removed.
• Management interfaces of network devices must be reachable only from a dedicated management network.
• Remote access must use an encrypted tunnel with multi-factor authentication, and wireless networks must use enterprise authentication.
• Up-to-date network diagrams, including data flows for Restricted information, must be kept and reviewed every [12 months].

Implemented through: the Communications and Operations Security Policy and the Network Security Procedure. Rule review records, network diagrams and device configuration backups are the evidence.

11.21 A.8.21 Security of network services

Where the network is delivered or managed by a provider, such as an internet carrier, managed security service, cloud connection or wireless operator, the security features and service levels are agreed in advance and checked in operation. The Organisation remains accountable for traffic that crosses a provider's network.

The supplier relationship owner is accountable for the agreement. The network team verifies technical delivery, and the Head of IT Security reviews provider assurance reports each year. The test of any network service is whether the Organisation could detect and survive its failure or compromise, and the agreement must support that.

• Every network service agreement must state the security features required, service levels, incident notification within [4 hours], and the right to audit or receive assurance reports.
• Traffic carrying Confidential or Restricted information over a provider network must be encrypted by the Organisation, whatever the provider offers.
• Internet-facing links must have denial-of-service protection with a stated capacity and a tested escalation route.
• Provider performance and security events must be reviewed at least every [quarter].
• A provider that fails its service levels twice in [6 months] must be reviewed for replacement.

Implemented through: the Supplier Relationship Management Policy, the Supplier Relationship Management Procedure, the Network Security Procedure and the Cloud Computing Security Policy and Procedure. Signed agreements, assurance reports and quarterly review notes are the evidence.

11.22 A.8.22 Segregation of networks

The network is divided into zones, each with its own trust level and rules, so that a compromise in one place cannot spread freely to another. Zones follow the sensitivity of data and the exposure of the systems in them, and traffic between zones passes through enforced controls.

The network team designs the zones and the Head of IT Security approves any new zone or change of rules. Application owners declare which zone their system belongs to. Network separation is combined with identity-based controls, so a flat or inherited rule never grants broad access merely because systems share a zone.

• Production, development, test, management, user, guest and customer-facing zones must be separated by filtering that denies traffic unless a rule allows it.
• Guest and personal-device networks must have no route to internal zones.
• Systems holding Restricted information must sit in a dedicated zone with only the flows documented in the data flow diagram.
• Segmentation must be tested by attempting forbidden connections at least every [12 months] and after a major network change.
• Cloud networks must use equivalent separation through virtual networks and security groups.

Implemented through: the Network Security Procedure, the Communications and Operations Security Policy and the Vulnerability Assessment and Penetration Testing Procedure. Zone diagrams, rule reviews and segmentation test reports are the evidence.

11.23 A.8.23 Web filtering

The Organisation controls which websites and web content its devices can reach, to reduce exposure to malicious sites, illegal content and uncontrolled uploads of data. Filtering applies on the corporate network and on managed devices wherever they are used.

The Head of IT Security owns the categories and exceptions list. The IT operations team runs the filter, and line managers may request exceptions for a business need. Staff are told in the Acceptable Usage Policy what is filtered and logged. Filtering is balanced against work needs, and the Organisation prefers education and a quick exception process to broad unexplained blocking.

• Categories blocked by default must include known malicious, phishing, newly registered domains, anonymisers, illegal content and unapproved file-sharing and generative AI services.
• The filter must apply to managed devices on any network through an agent or cloud gateway.
• An exception request must state the business reason and be approved by the line manager and IT security; it expires after [90 days].
• Web logs must be retained for [180 days] and reviewed for blocked-malware and policy-bypass attempts at least every [month].
• A malicious site found in use by staff must be blocked within [2 hours] of confirmation.

Implemented through: the Acceptable Usage Policy, the Network Security Procedure, the Malware Protection Policy and the Employee AI Usage Policy. The category policy, exception register and monthly blocked-access review are the evidence.

11.24 A.8.24 Use of cryptography

Cryptography is used wherever the risk assessment or a legal or contractual duty calls for confidentiality, integrity, authenticity or non-repudiation. The Organisation uses only well-reviewed, publicly analysed algorithms from approved libraries and never designs its own. Keys are treated as the most sensitive assets in the system.

The Head of IT Security owns the cryptographic standard. System owners apply it, and the key custodian runs key life cycle activities. Where law restricts or requires the use of cryptography, the Head of IT Security records the requirement and applies it before encryption is deployed.

• Algorithms and key lengths must meet at least the minimums in the table below; weaker ones must be retired on a plan agreed with IT security.
• Keys must be generated in an approved key management service or hardware module, stored apart from the data they protect and never in code or tickets.
• Keys must be rotated at least every [12 months], on suspected compromise and when a key holder leaves; a compromised key must be revoked within [4 hours].
• DES, 3DES, RC4, MD5 and SHA-1 must not be used for security purposes.
• Certificates must be inventoried, monitored and renewed at least [30 days] before expiry.

Implemented through: the Cryptography Policy, the Cryptography Procedure and the Key Management Process. The cryptographic inventory, key rotation records and certificate expiry reports are the evidence.

11.25 A.8.25 Secure development life cycle

Security is built into software and systems from the first idea to retirement and is not added at the end. Every project that builds or changes software follows a defined life cycle in which each phase has security activities and an exit check.

The engineering director is accountable for following the life cycle. Product owners include security requirements in the backlog, and the Head of IT Security defines the activities and acts as the final gatekeeper for high-risk releases. The life cycle applies to purchased and configured products as well as to code written in-house, with checks scaled to the risk.

• Each project must be assigned a risk tier at the start; high-risk tiers need a documented threat model before design is approved.
• Security requirements, abuse cases and acceptance criteria must be recorded in the backlog before development begins.
• The pipeline must run static analysis, dependency checks and secret scanning on every commit, and dynamic testing before release.
• Developers must complete secure development training at joining and then every [12 months].
• A release must not be approved with an open Critical or High finding unless the risk is accepted in writing by the product owner and the Head of IT Security.

Implemented through: the Systems Acquisition, Development and Maintenance Policy, the System Development and Maintenance Procedure and the Product Risk Assessment Procedure. Phase gate records, threat models and pipeline reports are the evidence.

11.26 A.8.26 Application security requirements

Before a system is built or bought, its security requirements are identified, written down and agreed, along with who will check them. Requirements come from the risk assessment, the classification of the data, customer and legal duties, and the environment where it will run. They are the basis of the tests in A.8.29.

The product owner is accountable for the requirement set. IT security supplies the standard catalogue, and the data protection officer adds privacy requirements for personal data. A requirement without a test is only an intention, so each one is tied to the verification activity that shows it was met.

• Each application must record requirements for authentication, authorisation, input validation, session handling, logging, data protection and error handling.
• Applications that process personal or payment data must record the lawful purpose, data minimisation, retention and deletion requirements.
• Applications reachable from the internet must be designed to resist the common web and interface attack classes, and APIs must authenticate every call.
• Requirements for purchased software must be sent to the supplier and answered in writing before selection.
• Requirements must be traced to tests so that each has evidence of verification at acceptance.

Implemented through: the Systems Acquisition, Development and Maintenance Policy, the Product Risk Assessment Procedure, the Data Protection and Privacy Policy and the Information Classification and Handling Policy. Requirement catalogues, traceability matrices and supplier responses are the evidence.

11.27 A.8.27 Secure system architecture and engineering principles

Design decisions follow security principles that are written down and applied the same way in every system. The Organisation prefers a small number of approved architecture patterns that already carry the right controls, and requires a reasoned justification for any departure.

The architecture lead is responsible for the principles and the pattern library. The design review board examines high-risk designs, and delivery teams are accountable for applying the principles to their own. Principles guide judgement but do not replace it, so a design that departs from them is accepted only with a recorded reason and a compensating control.

• Designs must apply least privilege, defence in depth, secure defaults, fail-secure behaviour and minimal attack surface.
• Every internal and external connection must authenticate and be authorised, and no connection may be trusted only because of its network location.
• Security-relevant decisions must be recorded in the design document and reviewed by the design review board for every high-risk system.
• Designs must show trust boundaries, data flows and the controls on each, and be updated when the system changes materially.
• The principles and approved patterns must be reviewed at least every [12 months].

Implemented through: the Systems Acquisition, Development and Maintenance Policy, the Secure Configuration Policy, the Cloud Computing Security Policy and Procedure and the Risk Management Policy. Design records, review board minutes and the pattern library are the evidence.

11.28 A.8.28 Secure coding

Code is written to a defined secure coding standard, reviewed by another person and checked by tools before it is merged. The aim is to avoid known classes of flaw in new code and in the open source and commercial components that the code depends on.

Engineering managers enforce the standard and the lead developer for each product keeps it current. Developers are accountable for the code they write, including the dependencies they choose. Reviewers are trained in common flaw classes and in the languages they review, so that review finds real defects and does not become a formality.

• A secure coding standard must exist for each language and framework in use and be reviewed every [12 months].
• Every change must be reviewed by at least [one] other developer who has not written it, with a security checklist for high-risk areas.
• Static analysis and dependency scanning must run on every merge request; findings of High severity or above must block the merge.
• Credentials, keys and personal data must never be embedded in code or test fixtures.
• Third-party components must come from approved sources, be listed in a software bill of materials and have High severity flaws fixed within [30 days].

Implemented through: the System Development and Maintenance Procedure, the Systems Acquisition, Development and Maintenance Policy and the Vulnerability Assessment and Penetration Testing Procedure. Code review records, scan results and the bill of materials are the evidence.

11.29 A.8.29 Security testing in development and acceptance

Security tests are run during development and before acceptance, and the results decide whether a system may go live. Tests complement the secure coding checks in A.8.28 by trying the whole running system as an attacker would, and are separate from the ongoing scanning of live systems in A.8.8.

The quality assurance lead runs functional and security test plans. IT security performs or commissions penetration testing for high-risk systems, and the product owner accepts the residual risk. Test depth is proportionate: low-risk internal tools receive automated testing only, whilst systems handling Restricted data receive independent human testing.

• Each release must run automated security tests, covering static, dependency and dynamic checks, with the results kept with the release record.
• Internet-facing and high-risk systems must have an independent penetration test before first release and after major change, and at least every [12 months].
• Acceptance criteria must include that no Critical or High findings remain open without a signed risk acceptance.
• Testers must use test environments and test data; testing in production needs a change record and the system owner's approval.
• Retests must be completed within [10 business days] of a fix.

Implemented through: the Vulnerability Assessment and Penetration Testing Procedure, the System Development and Maintenance Procedure and the Change Management Policy and Procedure. Test plans, penetration test reports and acceptance sign-offs are the evidence.

11.30 A.8.30 Outsourced development

When development is outsourced, the Organisation remains responsible for the security of what is delivered. Suppliers are chosen with this in mind, bound by contract to the same development standards as internal teams, and their output is checked before acceptance.

The product owner manages the supplier. The supplier relationship owner holds the contract, and IT security reviews the code and testing evidence before the deliverable is accepted. Quality of delivery is judged by the Organisation and not by the supplier's own assurance, so acceptance rights are kept in the contract until testing is complete.

• Contracts must require compliance with the secure coding standard, ownership of the code by the Organisation, confidentiality, and the right to audit.
• The supplier must disclose its use of subcontractors and open source components and keep the Organisation's code in a repository it controls or that the Organisation can export.
• Deliverables must pass malware scanning, static analysis and independent testing by the Organisation before acceptance.
• Supplier staff must hold access only to the repositories and environments they need, with accounts removed within [1 business day] after the work ends.
• Vulnerabilities in delivered code must be fixed by the supplier within the deadlines in the vulnerability management table.

Implemented through: the Supplier Relationship Management Policy, the Supplier Relationship Management Procedure, the Systems Acquisition, Development and Maintenance Policy and the Information Classification and Handling Policy. Contracts, acceptance test reports and supplier access reviews are the evidence.

11.31 A.8.31 Separation of development, test and production environments

Development, test and production run in separate environments so that errors, experiments and unfinished code cannot damage live services or reveal live data. The separation covers hosts, networks, accounts, credentials and data.

The IT operations team provisions the environments. Engineering managers make sure developers work only in the right environment, and the Head of IT Security checks that the separation is genuine. Where cost or technology makes physical separation impractical, logical separation is allowed only with the Head of IT Security's written approval and tested isolation. The same rule applies to shared cloud tenancy, and data protection obligations are not relaxed by environment names.

• Production, test and development must use separate networks or cloud accounts, with distinct credentials and keys in each.
• Developers must not have write access to production; changes reach production only through the release pipeline.
• Production data must not be copied to other environments except under A.8.33 Test information.
• Environments must be labelled visibly so that a person always knows which one they are working in.
• Emergency access by developers to production must be time-limited to [4 hours], approved and logged.

Implemented through: the Systems Acquisition, Development and Maintenance Policy, the Change Management Policy and Procedure, the Access Control Policy and the Network Security Procedure. Environment diagrams, access lists and pipeline records are the evidence.

11.32 A.8.32 Change management

Changes to systems, networks, applications, configurations and processes are requested, assessed, approved, tested, scheduled and reviewed, so that the services stay secure and available. Changes made outside this route are treated as security events.

The change manager runs the process. Requesters describe the change and its risk, approvers are chosen by change type, and the change advisory board meets to consider normal and emergency changes. Security-relevant changes, such as new network paths, privilege changes and encryption settings, receive review by IT security before approval. Changes by suppliers on the Organisation's systems follow the same route.

• Every change must be recorded in the ticketing tool with description, reason, risk rating, test evidence, rollback plan and implementation window.
• Changes must follow the types and lead times in the table below.
• No one may approve a change that they requested or will implement alone.
• Failed changes must be rolled back within the agreed window, and a post-implementation review must be done within [5 business days].
• The monthly report must compare changes found on systems with approved changes, and unauthorised changes must be raised as incidents.

Implemented through: the Change Management Policy and Procedure, the Problem Management Policy and Process and the Secure Configuration Policy. Change records, advisory board minutes and unauthorised change reports are the evidence.

11.33 A.8.33 Test information

Information used for testing is chosen so that real personal data, secrets and commercial information are not exposed in less protected environments. Where possible tests use synthetic data created for the purpose. Masking methods are described in A.8.11 Data masking.

The test lead is accountable for the data used. The data owner approves any copy of live data, and the data protection officer must be consulted when personal data is involved. The default is that no real personal data is found in test; any departure is deliberate, recorded and temporary.

• Test environments must use synthetic or irreversibly masked data by default.
• A copy of live data may be used only with written approval from the data owner and must carry the same controls as production.
• Copied live data must be deleted within [30 days] of the end of the test and the deletion recorded.
• Access to test data copies must be limited to the test team and logged, and the data must never be sent to an external party without approval.
• Test accounts and credentials must differ from production and be removed at the end of the test.

Implemented through: the Data Protection and Privacy Policy, the Data Governance Policy, the Systems Acquisition, Development and Maintenance Policy and the Information Classification and Handling Policy. Approvals for data copies, masking records and deletion logs are the evidence.

11.34 A.8.34 Protection of information systems during audit testing

Audit tests and other assurance activities on production systems are planned so that they do not disrupt services or expose information beyond what the audit needs. Auditors are given the least access that lets them do the work, for the shortest time.

The audit lead agrees scope with the system owner and the Head of IT Security. The system owner confirms the timing and the IT operations team sets up and removes access. The Organisation applies the same care to internal audit, external audit, customer audit and security assessments, whichever party performs them.

• The scope, systems, method, timing and tools of each audit test must be agreed in writing before it begins.
• Auditors must use read-only access wherever possible and use copies of data when full access to files is required.
• Intrusive tests such as scans and load tests must be run outside business-critical periods, or in a test environment, unless the system owner agrees otherwise.
• Audit activity must be logged and monitored, and access must be removed on the same day as the audit test ends.
• Copies of files taken for audit must be protected and deleted or returned within [30 days] of the audit report.

Implemented through: the Information Security Monitoring and Compliance Policy, the Vulnerability Assessment and Penetration Testing Procedure, the Access Control Policy and the Change Management Policy and Procedure. Audit plans, access records and removal confirmations are the evidence.

12. 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.

13. 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.

14. 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

• ISMS Manual
• Risk Management Policy
• Access Control Policy
• Acceptable Usage Policy
• Statement of Applicability
• Documents and Records Management Procedure