GCSB-PRC-TIA-001 Technology Integration and Architecture Procedure

Document control

1. Purpose

This procedure tells an adopting organisation exactly who does what, when and how to implement GCSB-ST-CSF-TIA-001. It converts the standard's technology requirements (clauses 6.1 to 6.10) into repeatable, auditable steps. It does not change, relax or extend any requirement of the standard; where this procedure and the standard differ, the standard prevails.

2. Scope and applicability

This procedure applies to every organisation adopting the Technology Integration and Architecture Standard. The standard uses the documented extended track: gap assessment within 6 months, foundation monitoring within 8 months, integration development and operational readiness within 12 months, full operational capability within 18 months of certification commencement, progress reports every 90 days, and final assessment within 60 days of declared full capability. Controls required by the Main Standard and the Risk Management Standard within their 12-month baseline continue to apply during this track.

3. Roles

4. Procedure

Step 1 - Record the adoption and scope (Week 1)

1. The governing body passes a written adoption decision naming the standard, edition (v2.0) and adoption date.
2. The CCSO records the adoption date in the implementation register. This date starts every clock in this procedure.
3. The adopter documents entities, facilities, systems, services, personnel, security domains, data flows, suppliers and material dependencies in scope, covering relevant SIEM, physical security monitoring, interfaces, identity services, cloud/hybrid infrastructure and analytics (clause 2.2). An absent OT estate is explained, not invented.
4. Exclusions, legacy limitations and externally controlled dependencies are recorded with risk and compensating arrangements.

Record: adoption decision; scope record; exclusions register.

Step 2 - Architecture and inventory (Months 1-6)

1. Technology owners maintain architecture and data-flow records identifying scoped systems, owners, dependencies, interfaces, trust boundaries, identity services and shared failure points across cyber, physical and OT (clause 6.1.1).
2. Architecture decisions document risk, continuity, safety, privacy, capacity and integration requirements with acceptance evidence (clause 6.1.2). SIEM/PSIM deployment may use a coordinated or federated architecture where equivalence is evidenced.
3. The adopter completes the initial architecture and existing-system gap assessment within 6 months of certification commencement (clause 7).

Record: architecture records; data-flow maps; gap assessment.

Step 3 - Cybersecurity monitoring coverage (Months 3-8)

1. The adopter collects and analyses relevant cybersecurity events from scoped network, endpoint, identity and application systems, with evidence of source identity, ingestion, time handling, completeness and authorised access (clause 6.2.1).
2. The eligible population of cybersecurity sources and the overall cross-domain population are defined separately; a coverage target is set and evidenced against the defined population (clause 6.2.2). Exclusions and critical uncovered dependencies are recorded.
3. Foundation monitoring (SIEM/PSIM or approved equivalent) covering the defined population is in place within 8 months (clause 7).

Record: source inventory; coverage definitions and evidence; monitoring deployment records.

Step 4 - Physical security monitoring (Months 3-8)

1. Information from relevant physical access, surveillance, intrusion, environmental and perimeter systems is coordinated within lawful scope, with traceable interfaces and appropriate access restrictions (clause 6.3.1).
2. Physical monitoring and command capability is outcome-based and proportionate to the estate; PSIM, centralisation, ONVIF and EN 50131/EN 50518 are applied where appropriate, not assumed mandatory for every estate (clause 6.3.2). Physical command actions respect emergency egress, safety and local operational authority.

Record: physical monitoring interface records; proportionality justification.

Step 5 - Interoperability and shared visibility (Months 6-12)

1. Cross-domain integration contracts, event semantics, access, integrity, error handling, supported response actions and interface-failure monitoring are documented and validated (clause 6.4.1). Cross-domain information sharing applies lawful minimisation.
2. Unified operational views display relevant threat information, incidents and metrics with role-based access, least privilege and traceable ownership; any "real-time" claim is defined by task and measured latency (clause 6.4.2).
3. Interfaces use justified security controls with controlled credentials, authorisation, transport protection and rate limits; protocol selections (mutual TLS, OAuth2, STIX/TAXII, ONVIF profiles) are documented per the adopter's architecture (clause 6.4.3).

Record: integration contracts; validation results; interface security records.

Step 6 - Identity, least privilege and zero trust (Months 6-12)

1. Access to integrated systems is governed through documented identities, roles, privileged access, authentication, lifecycle and review arrangements aligned with GCSB-ST-CSF-IAM-001; shared identity services have continuity and recovery arrangements (clause 6.5.1).
2. Zero-trust decisions, segmentation and least privilege address resources, users, devices, trust boundaries and context within scoped IT/OT operations; continuous authentication and dynamic micro-segmentation are evaluated against safety, availability and legacy constraints before deployment (clause 6.5.2).

Record: access governance records; zero-trust deployment evaluations.

Step 7 - Analytics and model assurance (Months 6-12)

1. Where analytics support operations, the adopter documents purpose, relevant data, lawful use, model limitations, validation, drift, error measures and accountable decision authority (clause 6.6.1).
2. AI/ML use is risk-based and conditional on scope; live testing requires authorised safeguards (clause 6.6.2).

Record: model assurance records; testing authorisations.

Step 8 - Authorised response and resilience (Months 9-12)

1. Cross-domain response procedures cover hybrid, systemic and cascading scenarios and integration failures, distinguishing incident type, severity and command/escalation level (clause 6.7.1).
2. Automated playbooks, orchestration, containment and physical/OT actions are bounded by documented authority, safety, privacy, continuity, logging and fallback (clause 6.7.2).
3. Failure of monitoring, identity, integration and analytics services is documented and exercised, with safe restoration validated; availability, recovery and detection targets are defined by service and measurement event (clause 6.7.3). A 99.9% availability target, where used, is indicative and confirmed by the adopter.

Record: response procedures; playbook authorisations; resilience exercise reports.

Step 9 - Privacy and information lifecycle (Months 6-12)

1. Actual controllers/processors, lawful bases, special-category conditions and required processing records are identified for integrated personal data (clause 6.8.1); security monitoring is not assumed automatically lawful under legitimate interests.
2. Data flows address necessity, minimisation, access, privacy by design and default, retention, subject rights, transfers and disposal (clause 6.8.2).
3. Breach procedures distinguish controller regulator notification, processor-to-controller reporting and affected-person communication; UK notification follows the UK statutory rule and EU notification the applicable EU and Member State period (clause 6.8.3).

Record: processing records; data-flow documentation; breach procedures.

Step 10 - Lifecycle, change, suppliers and measurement (Months 9-18)

1. Documented configuration, change, integration testing, supplier dependencies, operational procedures and incident evidence are maintained; material changes are assessed for risk, safety, privacy, interoperability and recognition implications (clause 6.9.1).
2. Technology assurance and access rights are kept lawful, necessary, bounded and independently governed; no recognition verification arrangement grants unrestricted technical access (clause 6.9.2).
3. Every coverage, availability, latency, correlation and effectiveness measure defines service/population, calculation, measurement window, evidence, target, owner, exclusions and escalation (clause 6.10.1).
4. Progress reports are submitted every 90 days; periodic performance reports and an annual self-assessment are maintained (clauses 6.10.2, 8).

Record: change records; metric definitions; progress and self-assessment reports.

Step 11 - Completion and final assessment (by Month 18, binding)

1. The CCSO verifies full operational capability against every requirement of clauses 6.1 to 6.10, with each requirement implemented or covered by an approved exception.
2. The final assessment is completed within 60 days of declared full capability (clause 7).
3. Any extension request is made at least 30 days before the affected milestone and handled under clause 9 of the standard.

Record: completion declaration; final assessment report.

Step 12 - Exceptions and scheme concessions (as needed)

1. The CCSO may approve temporary exceptions up to 12 months; longer exceptions only by the Board Risk Committee on recommendation of the Enterprise Risk Management Committee; all exceptions are reviewed quarterly (clause 9).
2. Each deviation records affected requirement, necessity, risk, compensating controls, owner, lawful authority, duration, review and remediation.
3. Scheme concessions are separate from internal exceptions: requested in writing at least 90 days before assessment with a mitigation plan, decided under the GCSB certification procedure, valid for no more than two years with reapplication. Cost or convenience alone is not sufficient justification; equivalence is evidenced, not asserted.

Record: exception register; concession requests and decisions.

5. Records and retention

All records named in this procedure are retained for the period set by the adopter's records policy and the standard's evidence duties, whichever is longer. This procedure creates no alternative retention period.

6. Related documents

• GCSB-ST-CSF-TIA-001 v2.0 (parent standard)
• GCSB-ST-CSF-001 Main Standard and GCSB-PRC-CSF-001
• Companion standards: GLA, RMA, IAM, DPP, IRBC, TRA and the CCSO Policy
• GCSB certification procedure (assessment, decision and concession clocks)

Revision history