ISO 27001 for IT managers 2: scope, obligations and information ownership

Start with the service the organisation delivers

Bring the charter from part 1 and invite people who understand delivery, HR, procurement and information use. Describe the service in business language before listing servers. For fictional Merefield, the service is consultancy delivery using customer working documents, staff expertise and cloud collaboration. The supporting laptops are important because of that information and activity.

Map the legal entity, locations, remote work, functions and interfaces. If only part of the organisation is in scope, explain its boundary and dependencies on shared identity, HR, finance or infrastructure. An excluded department can still provide an essential process to the ISMS. Do not assume that placing it outside the scope removes the need to control that dependency.

The final scope must describe what is managed accurately enough for employees, customers and auditors to understand. Avoid “all IT” if paper records, supplier personnel and business approvals are part of the information flow. Avoid an artificially tiny boundary chosen only to make assessment easier.

Trace information through one ordinary job

Choose a recent, suitably sanitised customer engagement. Follow the enquiry, proposal, contract, working files, delivery, invoicing and disposal. For each stage identify the information owner, storage location, access groups, transfers and retention decision. Ask where staff create extra copies, including personal notes or downloads.

This is not a demand for an expensive discovery platform. A table reviewed by people who do the work can uncover gaps that an automated asset list misses. Technical discovery then helps validate storage and access paths. Keep the two views together rather than assuming either is complete.

The rows are fictional examples. Replace them with actual owners and record unresolved decisions. Do not let the IT manager become the owner of every information asset merely because IT operates the storage.

Turn obligations into operational requirements

Create an obligations register with the source, applicability, responsible adviser/owner, required action and evidence. Sources can include customer contracts, legal and regulatory obligations, employment commitments and internal policies. Ask qualified colleagues to confirm applicability rather than deriving legal duties from a generic security checklist.

For example, a customer contract may require notification within a particular period or restrict subcontracting. Record the exact clause and the service it affects. IT then needs an incident escalation or supplier-change route that can meet that commitment. Do not invent a universal notification period or data-retention duration for every UK business.

When discussing personal information, involve the organisation's privacy lead and use current ICO guidance for the actual processing. Certification does not settle the lawfulness of processing, international transfers or employee monitoring. This series deliberately avoids prescribing a legal basis or retention period without the necessary context.

Include the 2024 context change

The climate-action amendment requires considering whether climate change is relevant to the management system and recognises that interested parties may have related requirements. For an IT manager, useful questions might concern availability during heat or flooding, supplier resilience and customer commitments that affect service delivery.

Record the assessment and reasoning. If a risk is relevant, connect it to the ordinary risk process and resulting actions. This is not an automatic requirement to create a separate carbon-reduction project inside the ISMS. A brief, reasoned conclusion supported by the organisation's circumstances is more useful than adding a decorative climate paragraph to a policy.

Revisit context when something meaningful changes: a new site, acquisition, service, customer obligation or supplier dependency. An annual meeting alone may be too slow for a major change. Choose triggers and ownership appropriate to the organisation; these are programme design choices, not fixed frequencies imposed by this tutorial.

Draft a scope that can survive questioning

Illustrative draft scope:
The management of information security for Merefield Services' consultancy delivery, including the people, processes and information systems supporting delivery from its office and remote working arrangements.
Interfaces to document: HR joiner/leaver notifications, finance records, outsourced IT support and cloud service providers.
Open decision: confirm whether a newly acquired service line is included before contracting the audit.

Walk that wording through the information map. Does it cover what the customer buys? Does it accidentally imply a subsidiary or product is certified when it is not? Can the internal team explain the boundary consistently? Agree the eventual certification wording with the certification body, supported by your actual ISMS scope.

Completion exercise

Choose one service dependency outside direct IT control. Identify the owner, the agreement, the evidence of operation and what happens if it fails. Then select one obligation and follow it to an operational action. If either ends at “someone else handles it”, assign a resolution.

Leave with an approved scope, context/interested-party record, information map and obligations register. Part 3 uses these to construct risk scenarios and a Statement of Applicability that reflects your organisation rather than a copied list of controls.

Check your understanding