Construction continuity depends on trusted information and clear decisions about what can proceed. A rehearsed response connects technical recovery with the people carrying out the work
When a construction project platform becomes unavailable, the immediate task is to establish which work can continue using verified information. Restoring access matters, but a rapid return to an untrusted record can create another problem. The response needs to consider confidentiality, integrity and availability separately.
A project recovery exercise
Use a hypothetical outage and safe test data to work through the response before an incident. Include the site team, design lead, information manager and the people responsible for the affected services.
| Exercise question | Evidence of a workable answer |
|---|---|
| Who coordinates the response? | Named contacts and an accessible communication route |
| Which work depends on the unavailable information? | A list of affected decisions and activities |
| Which records can still be trusted? | Verified versions and a controlled means of access |
| What must pause? | Decisions made by the responsible competent people |
| Can the service be recovered? | Tested restoration arrangements and an assessment of integrity |
| How will temporary records be reconciled? | A process for returning to one controlled history |
The exercise should expose unclear decisions and missing evidence without disrupting live systems. It should not encourage staff to bypass security controls or substitute uncontrolled copies for information needed to work safely.
Map dependencies before buying reassurance
The National Cyber Security Centre’s supply chain assessment guidance is aimed at procurement, risk and security teams seeking confidence in their suppliers. Its staged approach provides a useful foundation for examining construction relationships. A project dependency map should show who provides each important service, which information they hold or change and what other services they depend on. This can reveal a shared point of failure even when the project appears to use several independent suppliers.
Start with decisions whose interruption or corruption would have serious consequences. Approved design information, payment authorisations, site access and building controls may need different treatment from routine meeting documents. Record the maximum interruption each activity can tolerate and the people who determine whether work can continue. These are operational judgements, not numbers for a software vendor to choose alone. The exercise also makes procurement more specific: assurance should address the actual service and its dependencies, rather than rely on an impressive but unrelated certificate.
Give access an owner and an expiry
The NCSC’s guidance for small and medium-sized organisations brings together practical protection, incident planning and recovery resources. Its relevance extends to larger construction projects that depend on smaller firms. Basic measures such as supported software, secure accounts and resilient backups need to work at organisational boundaries. A project cannot assume that every participant has a dedicated security team, so onboarding should explain required controls in language a small business can act on.
Within a common data environment, named accounts make it easier to connect actions to authorised users. Permissions should follow the task: viewing a published drawing, uploading a proposal and approving its release are different activities. A temporary specialist should not retain broad access after their package finishes. Build joiner, mover and leaver checks into project administration, including people who change employer while remaining on the same scheme. Multifactor authentication and controlled privileged access need practical support so that inconvenience does not lead users to share credentials or move work into unmanaged channels.
Protect the integrity of released information
Availability attracts attention because an outage is obvious. Integrity can be harder to recognise. If a compromised user replaces a drawing, alters a payment destination or changes an equipment setting, people may continue working with apparently normal information. Project workflows should therefore separate preparation, checking and authorisation where consequences justify it. The evidence of approval should remain connected to the specific version, with a usable history of later changes. Merely showing that someone clicked an approval button does not explain what they approved.
Payment instructions deserve an independent verification route, particularly when bank details change. For technical information, identify how teams will establish which release was authoritative if an account or platform is compromised. Logs can help, provided they are retained, protected and available to the people investigating. A recovery plan that restores files without checking their status may reintroduce manipulated information. The project director and technical leads need to agree how confidence will be re-established before dependent activities resume, using proportionate checks for the affected work.
Treat connected assets as operational systems
Remote access to a building management system is different from access to a document library. Changes can affect physical operation, and maintenance windows may be constrained by building use. The NCSC’s operational technology guidance addresses systems that monitor or control physical processes. Its collection includes secure connectivity principles. For a connected building, security and engineering teams need to work together so that network changes, patching and emergency responses account for the consequences of interrupting the equipment.
At procurement, establish who owns administrative accounts, how remote support is authorised, which components require external connectivity and how long the supplier will support them. At handover, remove temporary commissioning arrangements and verify the intended operating configuration. A specialist’s remote connection should have a documented purpose and a route for revocation. Asset owners also need to know what happens if the supplier ceases trading or the connected service ends. These questions are easier to resolve before installation than after an unsupported controller becomes embedded in a critical building service.
Limit personal data and prepare the reporting route
Construction records can include identifiable workers, residents, visitors and members of the public. Photographs, access logs, incident reports and contact lists can carry personal data even when the main purpose of the system is technical. Give each collection a defined purpose and retention approach, and restrict access according to that purpose. Information useful for investigating an incident may not need to be visible to every project participant. Copying an entire dataset into a new analytics service can change the exposure without improving the underlying work.
The Information Commissioner’s Office’s personal data breach guidance explains the reporting threshold. A controller must notify the ICO without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to create a risk to individuals’ rights and freedoms. High-risk breaches can also require notification to affected people. Not every cyber incident is reportable, but assessment and recording are necessary. Project arrangements should make it clear who investigates, who informs the relevant controller and who decides on notifications.
Rehearse recovery with the people doing the work
A practical exercise can start with a hypothetical loss of the common data environment during a critical stage. Ask the site manager, design lead, commercial team and key subcontractor what they would do next. Can they obtain verified information? Which activities must pause? How will inspections and instructions be recorded without creating conflicting histories? The aim is to expose dependencies and unclear decisions while there is still time to improve them. An exercise should use safe test data and avoid disrupting live building or site controls.
Then test restoration. Backups are valuable only if the organisation can recover the necessary information, permissions and context within an acceptable period. Establish how much recent work could be lost and how it would be reconstructed. A cloud service’s general recovery capability may differ from the recovery available to an individual customer after accidental deletion or account compromise. Record the result of an actual recovery test, the unresolved gaps and the person responsible for correcting them. This is stronger evidence than a contractual assurance that backups exist.
Make resilience proportionate and accountable
Smaller suppliers need achievable requirements and a clear support route. A single questionnaire applied to every organisation can produce paperwork without revealing the risks that matter. Tailor checks to access and consequence, while maintaining essential controls across the project. Where a supplier cannot meet a requirement immediately, decide whether the work can be redesigned to reduce exposure, whether additional support is justified or whether access must wait. The decision should belong to an identified risk owner, with a review date rather than an indefinite exception.
PBC Today’s earlier article on understanding data and cyber resilience argued for better visibility across the business. Project teams can turn that principle into evidence through access reviews, dependency mapping and recovery exercises. Success is demonstrated when people know which work can continue, which decisions need renewed verification and who coordinates the response. That gives cyber security a practical place in project delivery, alongside the other controls that keep people, information and operations dependable.
The post A recovery checklist for a construction project platform outage appeared first on Planning, Building & Construction Today.
