GCSB-GDL-TIA-001 Technology Integration and Architecture Playbook

Document type: Guideline (advisory playbook) Parent procedure: GCSB-PRC-TIA-001 Technology Integration and Architecture Procedure Parent standard: GCSB-ST-CSF-TIA-001 Technology Integration and Architecture Standard, Version 2.0 Version: 1.0 Status: Issued Approved by: GCSB Governing Council, 19 October 2026 Effective: 19 October 2026 Next review: 19 October 2027 Prepared by: Global Converged Security Board (GCSB)

This playbook is advisory. It explains how to apply GCSB-PRC-TIA-001 in practice. Where this playbook and the parent standard or procedure differ, the standard and procedure prevail.

1. Purpose

The Technology Integration and Architecture standard requires that security is designed into technology - systems, networks, cloud services and the convergence of physical and digital infrastructure - rather than bolted on afterwards. The parent procedure fixes the implementation sequence and the 18-month extended track for architecture change. This playbook shows how to build secure architecture incrementally, with step-by-step guidance, worked examples, checklists and the records to keep.

The worked examples use the fictional Meridian Logistics Ltd (120 staff, head office, two warehouses, fleet operation, small IT team).

2. Guiding principles

• Architecture is a set of decisions, not a diagram. Record the decisions and their reasons; diagrams follow.
• Converge physical and digital. CCTV, access control and building systems are networked technology and belong in the same architecture and the same risk view as IT.
• Secure by default, simple by preference. The simplest architecture that meets the standard is the best one.
• Every system has an owner and an end-of-life. Unowned and immortal systems are where incidents live.

4. Scope and roles

This playbook applies to every organisation adopting GCSB-ST-CSF-TIA-001 through GCSB-PRC-TIA-001. It is advisory throughout: where it differs from the parent standard or procedure, the standard and procedure prevail.

5. Traceability

Play 1 - Inventory and map the estate (Procedure Steps 1-2)

Objective

Build a complete, current inventory of technology assets, including converged physical-security systems.

Step by step

1. Collect the sources: IT asset register, network scan, cloud account exports, finance procurement records, and the facilities list of building systems.
2. Reconcile them into one inventory; the union of the lists is the real estate. Investigate anything on any list that lacks an owner.
3. For each asset record: owner, purpose, data handled, dependencies, end-of-life date.
4. Explicitly hunt converged systems: CCTV, access control, alarms, building management, telematics - frequently absent from IT inventories and frequently network-connected.
5. Set a quarterly refresh cadence with a named owner for the inventory.

Worked example - Meridian Logistics

Reconciliation finds the IT register lists 41 assets; the network scan finds 53; finance records add 6 cloud subscriptions bought on expense cards; facilities adds the CCTV recorders, two door controllers, two alarm panels and the telematics platform - none previously in IT's register. Final inventory: 64 assets, each with an owner. Two unknown devices on the Warehouse South network turn out to be a contractor-installed Wi-Fi bridge - removed, and the removal recorded. The office manager owns the inventory; refresh is diarised quarterly.

Checklist

• At least three independent sources reconciled
• Converged physical-security systems included
• Every asset has an owner, purpose, data note and end-of-life date
• Unowned/unknown items investigated and resolved
• Quarterly refresh cadence set with a named owner

Records to keep

• The reconciled inventory, dated per refresh
• Source extracts used for reconciliation
• Resolution notes for unknown/unowned items

Common pitfalls

• Shadow IT and shadow OT. Cloud subscriptions on expense cards and contractor-installed building systems are the classic blind spots.
• Inventory as one-off. An inventory that is not refreshed is fiction within a year.

Measures of success

A scan or audit finds no significant asset missing from the inventory.

Play 2 - Define the target architecture (Procedure Step 2)

Objective

Set the target state: segmentation, identity-centred access, secure connectivity, and the place of each system in it.

Step by step

1. Write architecture principles on one page: e.g. "segment by default", "no implicit trust between zones", "all administration through managed identities", "physical-security systems on their own segment".
2. Define zones: user, server/application, converged physical systems, guest, management. Write down what may talk to what.
3. Map every inventoried system to its target zone.
4. Produce a phased roadmap from current to target state, aligned to the procedure's clocks; do not attempt a big-bang rebuild.
5. For each legacy system that cannot meet the target, register an exception with compensating measures and an end-of-life plan.
6. Approve principles, zone model and roadmap at the committee; record decisions and reasons.

Worked example - Meridian Logistics

Meridian adopts five principles and four zones. Key rule: the converged physical zone (CCTV, doors, alarms, telematics) has no direct internet access and talks to the user zone only through a managed jump point. Roadmap phase 1 (months 4-6): move CCTV and door controllers onto their own network segment at both warehouses. Phase 2 (months 7-9): separate guest Wi-Fi at all sites. Phase 3 (months 10-12): managed administrative identities for all critical systems. One exception registered: the legacy alarm panel cannot be segmented (expiry month 10, compensating measure: no remote access, weekly log checks).

Checklist

• Architecture principles adopted (one page)
• Zone model defined with allowed flows written down
• Every system mapped to a target zone
• Phased roadmap approved, aligned to the 12/18-month clocks
• Legacy exceptions registered with compensating measures and end-of-life plans
• Decisions and reasons recorded

Records to keep

• The principles document
• The zone model and allowed-flows table
• The system-to-zone mapping
• The phased roadmap and committee approval
• Exception register entries

Common pitfalls

• Principles without teeth. Principles that never cause a project to change are decoration. Record at least one decision per principle in the first year.
• Big-bang plans. Architecture change attempted in one step usually ends in rollback. Phase it.

Measures of success

The target state is written, approved, and every new project is checked against it.

Play 3 - Secure the build and change process (Procedure Steps 5-6)

Objective

Ensure new systems and changes are secure by design, as the standard requires.

Step by step

1. Add a lightweight security checkpoint to every project and significant change: data classification, zone placement, access model, logging, supplier assessment.
2. Start an approved-patterns catalogue ("standard site network", "standard cloud service") so projects reuse proven designs.
3. Require administration of critical systems through separate, managed administrative identities and devices.
4. Require security testing proportionate to criticality before go-live; record the results.
5. Route any checkpoint bypass through the exceptions register - never through deadline pressure.

Worked example - Meridian Logistics

When the customer portal project starts, the checkpoint catches: the vendor's default design puts the portal database in the user zone (corrected to the server zone), and the contract lacks a data-processing clause (added before signature). Go-live waits one week for a basic penetration test, which finds one medium issue (fixed before launch, retest recorded). The "standard cloud service" pattern is written from this project and reused for the HR system migration two months later, cutting its checkpoint to half a day.

Checklist

• Security checkpoint embedded in project/change process
• Approved-patterns catalogue started and growing
• Privileged administration model implemented for critical systems
• Pre-go-live testing recorded for critical systems
• Checkpoint bypasses only via the exceptions register

Records to keep

• Completed checkpoint forms per project/change
• The patterns catalogue with versions
• Test reports and retest evidence
• Exception entries for any bypass

Common pitfalls

• Checkpoint bypass under deadline. If escalation to a deadline-driven manager can skip the checkpoint, it will be skipped. Exceptions must be registered.
• Pattern drift. Review the patterns catalogue annually; yesterday's secure pattern becomes today's liability.

Measures of success

New systems arrive in the correct zone with correct access models; go-lives have recorded testing.

Play 4 - Operate and monitor the architecture (Procedure Steps 3-4 and 7-9)

Objective

Keep the running estate aligned with the architecture and visible to the security function.

Step by step

1. Centralise logging from all zones, including converged physical systems, with retention per the Data Protection standard.
2. Define the small set of alerts that always matter: unexpected flows between zones, new internet-facing services, unregistered assets on the network, administrative access from unmanaged devices.
3. Review the zone model and allowed flows quarterly at the committee; business change constantly erodes them.
4. Track every violation and finding to closure.

Worked example - Meridian Logistics

Meridian's alert set is five items. In September, an alert fires: a new internet-facing service appears at Warehouse North - a supplier's remote-maintenance connection to the door controllers, installed without telling anyone. It is disabled the same day, the supplier is required to use the managed jump point, and the event is minuted at the October committee. The quarterly review also tightens one allowed flow that a decommissioned system made obsolete.

Checklist

• Central logging covering all zones, including physical systems
• Small alert set defined and monitored
• Quarterly architecture review at the committee
• Violations and findings tracked to closure

Records to keep

• Logging coverage map and retention settings
• Alert definitions and alert handling records
• Quarterly review minutes and model changes
• Violation resolution records

Common pitfalls

• Logging without looking. Logs nobody reviews are storage, not monitoring. Define the handful of alerts that matter.
• Physical systems off the radar. CCTV and access-control systems must appear in monitoring like any other system.

Measures of success

Violations are detected and corrected; the quarterly review actually changes the model when the business changes.

Play 5 - Retire, review and evidence (Procedure Steps 10-12; binding clocks: monitoring coverage by month 8, progress reports every 90 days, completion by month 18)

Objective

Decommission systems securely, review the architecture annually, and keep the evidence trail.

Step by step

1. Run a decommissioning checklist per system: data migrated or destroyed per the Data Protection standard, accounts closed, DNS/certificates/licences released, network rules removed, inventory updated.
2. Set hard decommissioning dates; "keep it running just in case" needs an exception, not inertia.
3. Review the whole architecture annually against the standard and the latest threat analysis; record decisions.
4. Keep the evidence: principles, zone model, checkpoints, test records, review minutes.

Worked example - Meridian Logistics

The old file server is decommissioned in November: data migrated to the managed file store (migration verified by sampling 50 files), two service accounts closed, the server wiped with a destruction certificate filed, firewall rules removed, inventory updated. The annual architecture review in February records three decisions: adopt a second approved cloud pattern, bring the dashcam platform into the converged zone, and retire the last legacy alarm panel (closing the long-standing exception).

Checklist

• Decommissioning checklist in use, with data destruction evidence
• Hard dates set for retirements; exceptions for any extension
• Annual architecture review completed and minuted
• Evidence pack complete and retrievable

Records to keep

• Decommissioning checklists and destruction certificates
• Annual review minutes and decisions
• The architecture evidence pack

Common pitfalls

• Zombie systems. Systems "kept running just in case" accumulate unpatched risk. Set a hard date and decommission.

Measures of success

Nothing runs that is not in the inventory; the annual review demonstrably steers the roadmap.

4. Quick reference

5. Related documents

• GCSB-ST-CSF-TIA-001 Technology Integration and Architecture Standard, v2.0 (parent standard, sole normative source)
• GCSB-PRC-TIA-001 Technology Integration and Architecture Procedure (parent procedure)
• GCSB-ST-CSF-IAM-001 and GCSB-ST-CSF-DPP-001 (identity and data dependencies)

Version 1.0 - issued 19 October 2026. Copyright Global Converged Security Board.