This plan governs the handling of every incident affecting the KOM Oman AI Factory, from a failed fan tray to a confirmed intrusion. It deliberately uses one classification scheme and one command structure for physical, infrastructure and cyber events. A facility that runs two parallel incident processes discovers, at the worst moment, that nobody is certain which one applies — a cooling failure caused by a compromised building-management controller is both, and the response cannot pause to decide.

The plan is owned by the CISO jointly with the COO: the COO owns availability of the facility, the CISO owns the integrity of the systems that run it. Where the two conflict during an incident, section 05 states which authority prevails and when.

The boundary is the leaf-switch customer port and the rack door. Prima owns everything up to it; the customer owns what runs behind it. Where an incident crosses that boundary — a Prima fault that corrupts a customer job, or a customer workload that causes a thermal excursion — section 05 provides for a joint incident, run by a Prima incident commander with a named customer counterpart.

Incidents are classified on impact, never on cause. This matters more than it sounds: classifying on cause invites argument at the moment argument is most expensive, and it systematically under-rates novel failures because they do not match a known category. A total loss of compute is a P1 whether the cause is a transformer, a firmware bug or an intruder.

1. Classify on first information, revise on evidence. The initial severity is set by the NOC within five minutes on the information available. Under-classification is corrected upward the moment evidence supports it; the clock does not restart on re-classification.
2. Doubt escalates. Where severity is genuinely unclear, the higher level applies until an incident commander rules otherwise. It is cheaper to stand down a P1 than to discover a P2 was one.
3. Any suspected compromise of OT is P1. BMS, EPMS and access-control systems have physical consequence. Suspicion is sufficient; confirmation is not required to open at P1.
4. Security severity cannot be reduced by an operations owner. Only the CISO or delegate may lower the severity of a security incident, and the decision is recorded with its reasoning.
5. Customer-visible impact sets a floor. If a customer has lost committed capacity, the incident is at least P1 regardless of how routine the internal cause appears.

Every incident enters through the Network Operations Centre, whatever its origin. There is no second queue: an incident reported to an engineer in a corridor is not an incident until the NOC holds it, and staff are trained to route rather than absorb. This single-intake rule is what makes the response clock and the availability record trustworthy.

Triage is a NOC function and is not delegated. The engineer on shift may open at any severity, page any escalation level and summon the security path without seeking permission — a triage function that must ask before escalating does not escalate in time.

At triage the NOC asks one additional question of every incident: could this be caused by someone rather than something? Where the answer is yes or unknown, the incident takes the security path in parallel with the operational one — because the operational instinct is to restore quickly, and restoring quickly frequently destroys the evidence an investigation needs.

Every incident runs the same six phases. Small incidents pass through some of them in seconds; a P1 may hold in containment for hours. The value of a fixed lifecycle is that at any moment every participant can state which phase the incident is in, and therefore what is and is not being attempted.

Containment precedes restoration in every case, strictly so on the security path: restoring a compromised system without containing the compromise reinfects it, destroys the evidence and starts the incident again with less telemetry than before. On the operational path containment is often instantaneous — the design is concurrently maintainable, so isolating a failed UPS string is the containment step.

A security incident additionally requires the CISO's written concurrence to close. Where root cause is unestablished, the incident closes operationally but the security case stays open — tracked separately, so a restored service is never mistaken for a resolved compromise.

Escalation is time-based and automatic. It does not wait for a request, and it is not a judgement about competence — it is a standing rule that puts progressively more authority next to a problem that is taking progressively longer. A P1 unresolved at two hours reaches the COO whether or not anyone asked for help.

On the security path the ladder runs in parallel: CISO on-call at detection, CISO at 15 minutes, CEO and General Counsel at 2 hours where a breach is confirmed or credibly suspected. A P1 unresolved at four hours produces a formal incident notice to the affected customers within the same hour.

During a security incident the fastest route to restoration and the correct route to containment sometimes diverge. That conflict is resolved in advance rather than negotiated under pressure.

1. The CISO may hold restoration where restoring would destroy evidence or reinfect a contained system. The hold is recorded, with its reasoning, and reviewed every 30 minutes.
2. The COO may overrule a hold where continued unavailability presents a greater risk to the customer than the loss of evidence. The overrule is recorded in the same way.
3. A hold that reaches 2 hours goes to the CEO for decision. Neither the CISO nor the COO carries that trade-off alone beyond two hours.
4. The customer is told a hold is in effect and why, in general terms, within the notification cycle. A customer discovering afterwards that restoration was deliberately delayed without being told loses more trust than the delay itself costs.

Customers are notified on a schedule, without asking. A customer who has to chase for status during an outage is having two problems, and the second one is ours. Notification is the communications lead's sole responsibility so that it continues while the technical work does.

A security incident affecting a customer's environment or data is notified within 24 hours of confirmation, irrespective of its operational severity, and thereafter as material facts change rather than on a fixed cycle — section 12 sets out the regulatory obligations that run alongside.

1. No speculation on cause. Cause is stated only when established — early speculation is usually wrong and is remembered longer than the correction.
2. No silent slippage. If a restoration estimate is going to be missed, the notification goes out before the estimate expires, not after.
3. Bad news travels at the same speed as good. A worsening incident is notified immediately, outside the cycle.
4. One voice. Only the communications lead speaks to customers during an incident. Engineers do not give parallel estimates, however well-intended.
5. Written record. Every notification is recorded against the ticket; the monthly report reproduces the P1 and P2 notification history.

A restored service is not a resolved incident. Root-cause analysis is a deliverable with a deadline, not an aspiration, and its output is a set of dated commitments that are tracked to completion in the same register as the incident itself.

Analysis follows a structured causal method — successive why questions from the observed failure to the conditions that permitted it, with contributing factors recorded separately from the proximate cause. Two rules give the method its value:

• Human error is a symptom, not a cause. Where a person made a mistake, the analysis continues into why the system permitted it — the missing interlock, the ambiguous procedure, the alarm that was routinely ignored. An RCA that terminates at a name has stopped one step early and will not prevent recurrence.
• Detection is analysed alongside cause. Every RCA answers how long the condition existed before it was seen, and whether it could have been seen sooner. A fault found by a customer rather than by the NOC is a monitoring finding in its own right.

Customers affected by a P1 receive the sanitised RCA: full timeline, cause, availability impact and corrective actions, with other customers' identities, third-party commercial terms and security-sensitive detail removed. Sanitisation removes information that would harm another party — it does not remove information that is unflattering to Prima. Where a security-sensitive control is at issue, the RCA states that a control was involved and that it has been remediated, without describing it in a way that would assist an attacker.

A GPU facility is an unusual target: it concentrates very high-value data and operational technology whose compromise has immediate physical consequence. The threat model below drives the playbooks in sections 09 and 10, and is reviewed twice yearly and after any material change to the estate.

1. Assume breach. Prevention is assumed to fail at some point, so detection, containment and evidence receive as much design attention as the perimeter.
2. OT is not defended by obscurity. Building-management and power-monitoring protocols are legacy and weakly authenticated; segmentation and monitoring carry the defence, not the protocols.
3. Customer data is presumed sensitive and encrypted at rest by the customer. Prima does not require knowledge of what a customer runs, and designs so that it need not.
4. Legitimate credentials are the likely vector. Response is built around anomaly, not signature: a valid session behaving unusually is likelier than a novel exploit.
5. Physical and cyber converge. An access-control anomaly is a cyber signal and a cyber anomaly can be a physical precursor. One incident process, per section 01.

Each playbook states the first action — where incidents are won or lost, and the one decision that must not fall to whoever happens to be nearest.

These three playbooks share a property that changes the response: compromise produces physical effect, not merely data loss — cooling stopped, breakers opened, doors released. The response therefore prioritises reverting to manual control over investigating in place.

Evidence decisions are made in the first minutes and cannot be revisited, so the rule is simple enough to apply under pressure: preserve before you repair, and where the two genuinely conflict, escalate rather than choose alone.

1. The General Counsel may impose a legal hold at any point, suspending all routine deletion across identified systems. A hold is issued in writing to named custodians and remains until released in writing.
2. External forensic support is pre-arranged, not sourced during an incident — a retained provider is engaged on the CISO's authority with no procurement step.
3. Law-enforcement engagement is a CEO and General Counsel decision, taken on advice from the CISO. Where a request is received rather than initiated, the Law-enforcement access policy in the Physical Security Specification governs.
4. Insurer notification is made by the CFO within the period the cyber policy requires, and is not deferred pending investigation — late notice can void cover.
5. Customer participation. Where a customer's data or environment is implicated, the customer may nominate its own forensic representative, who is given access to the relevant evidence under a confidentiality undertaking.

The Company holds no breach history. That statement requires context to be worth anything, and the context is this: the KOM Oman AI Factory is pre-operational, with ready-for-service in December 2026. A facility that has not yet carried a customer workload has had no opportunity to accumulate an incident record. A nil return is a statement of fact about elapsed time, not evidence of operational resilience, and it is recorded here as such.

1. The incident record begins at ready-for-service and is maintained continuously thereafter, without a grace period for the commissioning phase.
2. Commissioning incidents are recorded under this plan from first energisation, before any customer workload is present, so that the record covers the plant's whole life rather than its commercial life.
3. Sanitised RCAs become available to customers and auditors on request from the first incident, without a waiting period and without a separate approval.
4. The monthly service report carries the incident history from the first month of service — availability, every P1 and P2 with response times against target, and RCA status.
5. Prior operating experience elsewhere is never presented as this facility's record. Where the operating team's experience at other sites is relevant, it is offered as team experience and labelled as such.

A response plan that has never been rehearsed is a document, not a capability. The exercise programme is the mechanism by which this plan is known to work, and its findings are tracked in the same corrective-action register as real incidents.

Exercise findings are raised as corrective actions with owners and dates, tracked identically to those arising from real incidents. An exercise that produces no findings is treated as insufficiently demanding and its scenario is revised.

Of these, detection quality is watched most closely. Response and restoration times measure how well the team performs once it knows; the share of incidents a customer had to tell us about measures whether we knew at all.