Structure, cadence, and clear ownership.
Projects fail when risks are scattered across emails and memories. This page gives you one structure—fields, owners, cadence—to capture threats, utilities clashes, programme slips, and approval gaps. You’ll link rating-critical dependencies and evidence sources so HVM bollard and crash rated bollard decisions stay traceable, defensible, and updated as conditions change. Include one-sentence context that naturally links upward to the parent hubs (this section and the chapter hub). Add SIRA context with a link to SIRA Bollards (UAE) when relevant. Link installation pages only if helpful: What to Expect and Installation Guide.
Important: This is a general guide. For live projects we develop a tailored
Method Statement & Risk Assessment (MS/RA) and align with authority approvals (e.g., SIRA) where in scope.
846.1 Structure & fields
Cause, event, impact, owner, due date, status. Structure clarifies HVM bollard exposure.
Use a single, lightweight table to record each risk. For every entry, capture the cause (what sets the conditions), the event (what might happen), and the impact (what it means for programme, cost, quality, or safety). Add an accountable owner, next action, due date, and current RAG status. Keep the description short and use links to evidence (surveys, approvals, calculations) so the register stays readable yet fully traceable.
Where the risk touches security performance, tie the description back to your VDA method and the chosen crash rating. For example, note if a utilities clash may force a shallower footing that jeopardises rating-critical dependencies.
Owners should be singular and accountable. If delivery is shared, add a compliance check cadence and a comment that clarifies decision rights (e.g., designer vs contractor). Update status weekly; archive superseded text rather than overwriting to preserve the audit trail.
| Aspect | What matters | Where to verify |
|---|---|---|
| Performance | System = bollard + foundation as tested | Global crash ratings |
| Operations | Duty cycles, fail-state, safety devices & measures | Installation Guide |
846.2 Sources & updates
VDA, surveys, utilities, programme (221, 241, 855). Sources keep crash rated bollard risk current.
Anchor every risk to a source that actually changes over time: the VDA method overview (221), utility search methods (241), and the live programme & phasing plan (855). When a survey, drawing, or approval is updated, log the new file name per File Index & Naming Rules (911) and paste the evidence URL into the risk row.
For UAE projects, capture SIRA prerequisites (where in scope) and link to the SIRA Bollards (UAE) hub so reviewers can see authority expectations quickly.
846.3 Mitigation plans
Concrete actions with costs (841). Plans reduce HVM bollard variability.
Each red or amber risk should have a mitigation plan with specific actions, an owner, and a cost/time impact estimate. Reference cost logic from Cost ranges: HVM vs Low-Speed (841) and call out any value engineering trade-offs. Example: switching to a shallower foundation to clear a duct may force a different product family or array geometry.
List residual risk after mitigation and the risk assessment reference that will be updated.
846.4 Triggers & thresholds
Escalation rules for red risks (738). Thresholds protect crash rated bollard delivery.
Define clear triggers (what changes move a risk up a band) and thresholds (how big the change must be). Typical triggers: utilities re-marking that pushes a bollard into a hand-dig zone, lead-time slippage against the critical path, or revised VDA assumptions. For red risks, state the escalation path and response window, and tie service impacts to Service Levels & Availability (738).
846.5 Dependencies
Link to rating-critical items (421). Dependencies preserve HVM bollard certification.
Where a risk could change the tested configuration, link directly to rating-critical dependencies (421) and record the precise constraint (e.g., minimum footing depth, rebar cage layout, or grout strength at time of commissioning). Add a reminder to check comparable evidence in the documentation & certificates pack (431).
846.6 Interface risks
Controls–civils–utilities (247). Interface clarity prevents crash rated bollard rework.
Most delivery issues arise at interfaces—civils with utilities, controls with civils, and operations with both. Use a shared trade coordination log (247) and mark each risk row with the affected discipline. Where controls are involved, reference the Change Control & Versioning page (537) so any firmware/config change is tracked.
846.7 Review cadence
Weekly tactical, monthly strategic (728). Cadence maintains HVM bollard focus.
Run a 15-minute weekly stand-up to hit overdue items and new entries, and a monthly strategic review to re-score top risks, retire closed items, and confirm owners. Log outcomes in the site audit & compliance checks record (728) and cross-reference the progress reporting & controls pack (859).
846.8 Audit trail
Changes logged under 911 (537). Trail proves crash rated bollard governance.
Never delete a risk; close it with a final status and keep the history. Store supporting files using File Index & Naming Rules (911) and record configuration changes per Change Control & Versioning (537). This audit trail underpins handover quality and protects the project if decisions are challenged later.
846.9 Heat maps & reports
Visual risk dashboards (544). Visuals drive HVM bollard decisions.
Summarise the register into a simple heat map and a short “executive snapshot” for stakeholders. Map likelihood bands against consequence categories that matter for HVM: security performance, cost, time, and safety. Publish the dashboard alongside the operational dashboards & reporting view (544) so project and operations teams speak the same language.
Related
External resources
- ASIS Security Risk Assessment Standard
- NPSA: Hostile Vehicle Mitigation
- FEMA 426 / DHS Reference Manual
846 Risk Register & Governance — FAQ
What fields should every HVM project risk register include?
At minimum: cause, event, impact, owner, next action, due date, status (RAG), and links to evidence. For security items, reference the relevant VDA, crash rating page, and any rating-critical dependency that could be affected.
How often should we review the register?
Hold a weekly tactical check for updates and overdue actions, and a monthly strategic review to re-score top risks, confirm owners, and close completed items. Capture outcomes in the site audits & compliance checks record.
What’s the link between risks and programme slippage?
Each risk should cite the affected activity or milestone in the live programme & phasing plan. If a risk turns red, apply the escalation path and update float, dependencies, and mitigation actions immediately.
How do we prove governance at handover?
Use a preserved audit trail: closed risks with final status, linked evidence named per File Index & Naming Rules, and a versioned change log for any controls or configuration changes per Change Control & Versioning.