Sections 02 to 06 are the inputs a certification body asks for first. Sections 07 and 08 are the applicability decision on every Annex A control — the document an auditor works through line by line. Section 09 states honestly what is written and what is not. Sections 10 and 11 set the sequence.

ISO/IEC 27001 certifies a management system, not a building. This matters more than it sounds: it means the standard can be certified against the legal entity and its way of working before the facility it protects is energised. The common assumption — that certification must wait for the data centre to open — costs a year for no reason.

What cannot be shortened is the sequence a certification body follows. It begins by asking for four things: the scope, the assets, the risk assessment, and the decision taken on every control in Annex A. Only when those exist does it proceed to a stage 1 audit. A project that arrives without them spends its first six weeks producing them under time pressure, with the auditor waiting.

This document produces them in advance. It is written to be handed to a certification body at first contact, so that the response is a quotation against a defined scope rather than a request for the basics.

1. The scope statement — in the exact words that will appear on the certificate, with anything excluded stated and justified. Section 02.
2. The interested parties and what each requires of the ISMS. Section 03.
3. The information assets in scope, by class rather than by item. Section 04.
4. The risk assessment method and the criteria for accepting a risk, plus the register itself. Sections 05 and 06.
5. The Statement of Applicability — a decision on all 93 Annex A controls, with a reason for every exclusion. Sections 07 and 08.
6. The policy set, an internal audit programme, and evidence of management review. Section 09 states which exist.

The scope is the single most consequential sentence in a certification. It determines what the certificate proves, what the auditor may examine, and what a customer is entitled to rely on. A scope drawn too narrowly produces a certificate that does not cover the service being sold; drawn too widely, it commits the organisation to controls over things it does not govern.

A site-only scope is easier to certify and materially less useful. The information a customer actually cares about — its contract, its capacity commitments, its technical requirements, the correspondence in which it disclosed them — lives in the company's systems, not in the data hall. A certificate that covers the hall and not the company answers the wrong question.

The wider scope also settles a question a reviewer will otherwise ask: whether the certificate covers the entity contracting with them. Naming the legal entity and its registration number removes the ambiguity.

An exclusion without a reason is a finding. Each of the following is outside scope because it is outside Prima's control, not because it is inconvenient.

Three interfaces are neither in scope nor simply excluded — responsibility is shared, and the ISMS must show how. An auditor will test these specifically, because shared boundaries are where controls are most often assumed by both parties and held by neither.

• Vendor remote access. The vendor holds its own credentials and its own conduct; Prima holds the gateway, the authentication, the session recording and the authorisation. Prima's side is in scope.
• Construction and commissioning contractors. Their working practices are theirs; their access to the site and to information about it is Prima's. Governed under PRM-SEC-2026-001 and PRM-HR-2026-001.
• The consortium. Information shared with Awasr, ElioVP and Hydra under the joint venture is in scope while in Prima's custody. What each partner does within its own organisation is not, and is addressed by agreement rather than by this certificate.

Clause 4.2 of the standard requires the organisation to identify who has a stake in its information security and what each of them needs. The value of the exercise is not the list — it is that the risk register at section 06 can then be tested against real expectations rather than generic ones.

Assets are identified by class, not by item. An inventory of individual files is unmaintainable and tells an auditor nothing; a classification with an owner, a handling rule and a retention period is what the controls actually attach to.

Customer workload data does not appear on this list, because Prima does not hold it. Bare-metal capacity means the customer administers its own systems and Prima has no logical access to what runs on them. This is the single most important fact about Prima's information risk profile, and it changes the shape of the whole register: the risk is unauthorised access to infrastructure, not misuse of data in Prima's custody.

Naming an owner in the table above is not a formality. Each owner carries four duties, and an auditor will ask any one of them to demonstrate the fourth.

1. Classification. Deciding the class of new information in their area, and correcting it where it has been set wrongly. Classification drifts downward if nobody owns it — material starts Confidential and is treated as Internal within a year.
2. Access. Approving who may reach it, and confirming at each recertification cycle that the list still reflects need rather than history.
3. Retention. Ensuring it is kept for as long as it is needed and no longer. Records held past their retention period are a liability, not an asset.
4. Disposal. Authorising destruction when retention expires, to the standard set for the media in PRM-SEC-2026-001 §10.

Reviewed annually, and on any change to the service offering, the customer base or the systems that hold the information. A new asset class is added when a new kind of information enters the organisation — most commonly through a new contract form or a new system, which is why procurement and legal are both represented among the owners.

The standard does not prescribe a method; it requires that the method be defined, repeatable and consistently applied. What follows is deliberately simple, because a method too elaborate to repeat produces a register that is scored once and never revisited.

Each risk is written as threat acting on asset, causing consequence — not as a topic. “Insider access” is a topic and cannot be scored. “A contractor with unsupervised hall access removes a drive containing customer configuration data” is a risk, and the controls that reduce it are obvious from the sentence.

• Inherent score is recorded before controls, residual after. A register showing only residual scores hides how much work the controls are doing, and an auditor cannot test a control whose contribution is invisible.
• No risk is closed, only reduced or accepted. Closure implies the threat has gone. Threats do not go; controls change.
• Acceptance is time-limited. Every accepted risk carries a review date. An acceptance with no expiry becomes a permanent exception nobody revisits.
• Reviewed quarterly, and on any change to the scope, the plant, the customer base or the threat picture. Also after any incident, whether or not the incident was in the register — an incident that was not anticipated is a finding against the method, not just against operations.
• Safety risks are not traded against commercial ones. Any risk with a safety consequence is scored at impact 5 and cannot be accepted below the CEO.

Twelve risks, each traceable to a requirement in section 03 and to controls in sections 07 and 08. The register is deliberately short: a hundred-line register is a document nobody reads, and the controls that matter are driven by a dozen scenarios.

Three observations a reviewer should be able to draw from the twelve lines above, stated rather than left to inference.

• The dominant risk is access, not data. Five of the twelve concern someone reaching infrastructure they should not — physical, logical, vendor, insider or tenant. Only two concern information in Prima’s custody. That follows directly from holding no customer workload data, and it is why the control emphasis sits on access and segregation.
• Two risks carry a residual of 8 pending a document that is not yet written. R02 waits on the OT security architecture, R10 on the data-protection policy. Both are named at 9.2 with an owner. Neither is hidden in a footnote.
• No risk sits above the acceptance threshold after treatment. Every residual is 8 or below, which is inside the medium band and acceptable at CISO level. Two are at the top of that band, which is why they carry outstanding actions rather than acceptances.

A decision on every one of the 93 controls in Annex A of ISO/IEC 27001:2022. Applicable means the control is in force or scheduled; Partial means in force but with a named gap; Excluded means not applicable, with the reason stated. Eighty-eight are applicable in whole or part — 70 in full and 18 with a named gap — and five are excluded — all five for the same reason, at 8.34.

Of the 37 organisational controls, 27 are applicable and in force, ten are partial. Every partial traces to one of two causes, and neither requires a third party: a policy that has not been written yet, or a record that cannot exist until the management system has been operating. Both are itemised at section 09.

Eight controls, all applicable. This group is the best-covered in the whole Statement of Applicability, because PRM-HR-2026-001 was written against a facility where the people with unsupervised access are the primary risk — which is exactly what these controls address.

Three of the twelve risks in section 06 — insider abuse of privilege, unauthorised physical access, and vendor access left open — are reduced principally by these eight controls rather than by any technical measure. A facility can be perfectly segmented and still lose customer confidence to one improperly vetted contractor with a hall pass.

The fourteen physical controls are the group a data-centre operator is judged on hardest, and the group where Prima has the most written. None is excluded — twelve are applicable in full and two carry a named gap. Eight rest directly on PRM-SEC-2026-001.

All five excluded controls — A.8.25, A.8.26, A.8.28, A.8.29 and A.8.30 — are excluded for one reason: Prima is an infrastructure operator, not a software developer. It writes no product code, ships no application, and runs no development pipeline.

The exclusion is stated narrowly on purpose. A.8.27 sits in the middle of the same group and is applicable, because secure architecture and engineering principles govern how the platform and the OT estate are designed — which Prima very much does. An auditor should read the boundary as drawn between building software and engineering infrastructure, not between technology and everything else.

A readiness document that does not state its own gaps is worthless to the party reading it. This section lists what exists, what is missing, and what cannot exist yet — in that order.

Forty-four distinct Annex A controls are evidenced by a document already written and in issue — counted as the distinct controls named in the third column below. A.8.29 is cited for context only and is not counted, being one of the five exclusions.

Three requirements are not gaps in preparation — they are consequences of the management system being new. Stating them prevents a reviewer treating them as oversights.

• Internal audit evidence. Clause 9.2 requires the ISMS to have been audited internally. There is nothing to audit until it has operated. First internal audit is programmed for Nov 2026, once the policy set is in force.
• Management review records. Clause 9.3 requires evidence that management has reviewed the system's performance. First review Dec 2026, with the second before the stage 2 audit.
• Operational records against the controls. Access recertification cycles, drill grades, incident records, training completions. These begin accruing from Q3 2026 as the resident team is recruited, and reach a reviewable body by Q4.

Not the documents, and not the facility. The appointment of the certification body. Accredited bodies in the region schedule stage 1 and stage 2 audits months ahead, and a slip in appointment moves the certificate by a full quarter regardless of how ready the ISMS is.

The diligence line asks for three certificates. They do not sequence equally, and treating them as one workstream would delay all three.

Clause 9.1 requires the effectiveness of the ISMS to be monitored and measured. Reported to the COO on the cadence shown, and to the board quarterly.

Stated in four lines so that a reviewer, a lender or a certification body can take the position without reading the document.

• Scope, assets, risk method, register and Statement of Applicability exist — the four inputs a certification body asks for at first contact. 93 controls decided: 70 applicable, 18 partial, 5 excluded with reason.
• Forty-four controls are already backed by a document in issue, listed at 9.1 and openable today. The people-controls group is complete, and the physical group carries only two partials.
• Nine policies remain to be written, all internal, three owners, targeted Aug to Oct 2026. Nothing at 9.2 waits on a vendor, a certificate or a building.
• No certificate is held. First target is ISO/IEC 27001 in Q1 2027, then 22301 and 45001 in Q2 2027 reusing the same management system. The binding dependency is appointing an accredited body in August — not the documents, and not the facility.