Every major project makes security decisions. Most make them implicitly.
Supplier selection determines what technical debt the organisation will live with for decades. Architecture choices set network boundaries that constrain every future integration. Data flow decisions create compliance obligations before anyone consults the compliance team. These are security decisions. They just don’t look like security decisions when the project team is evaluating functionality, cost, and operational fit.
For understanding the threat landscape, assessing risk proportionately, integrating enterprise security capabilities and making trade-offs explicitly rather than by default, the system security concept aligned to buy-build-run project phases is one way to do it. It identifies the security activities, decisions, and deliverables that need planning and resourcing at each stage.
This article covers one system, one security concept, one project lifecycle. The framework applies regardless of industry or technology, IT and OT alike. Larger programmes, a mill implementation, a global ERP rollout, a platform consolidation, involve multiple systems each with their own security concept and scope. A programme-level security concept establishes the foundation, including integration with enterprise security capabilities, while individual system concepts address the specifics of each system within the programme. The buy-build-run alignment described here applies at each system level.
Security activities aligned to standard project gate phases. The system security concept spans the full lifecycle, created during initiation and maintained through to operations. Based on the Stage-Gate model (Cooper, 1990).
What misalignment actually costs
A site invests in a new manufacturing execution system. An organisation replaces its ERP platform. A business unit rolls out a new CRM across multiple regions. The project evaluates suppliers on functionality, cost, and integration with existing workflows. Months into implementation, someone raises authentication, network segmentation, or how the system connects to the corporate network.
The answers are expensive. The supplier’s architecture assumes flat network access. The authentication model doesn’t support the organisation’s identity provider. Data flows cross boundaries nobody considered during design. Retrofitting security into a system that wasn’t designed for it costs more, takes longer, and produces weaker outcomes than building it in from the start.
The pattern repeats at every scale and in every sector. A platform migration. A quality management upgrade. A new supplier portal connecting to business-critical systems. Each has phases, and in each case security requirements surface after the decisions they should have informed.
Buy: the highest-leverage phase
The buy phase is where supplier and system selection happens. It is also where security input has the most leverage.
A current security concept for the system being replaced already contains the business criticality assessment, the risk profile, the integration requirements, and the control architecture. That is a ready-made set of requirements for supplier evaluation, derived from this specific system’s context. Not a generic checklist.
What authentication standards must the new system support? What data classification applies? What network boundaries will it operate within? What monitoring does operations need? What are the recovery requirements based on business criticality? These questions come directly from the security concept. A supplier that can’t meet them creates risk the organisation has already assessed and decided it doesn’t want to carry.
Procurement teams can embed these requirements into RFPs and supplier assessments. The security concept turns ‘we need to involve security’ from a vague obligation into a specific input with measurable criteria.
Build: architecture, not afterthought
Once a supplier is selected and implementation begins, the security concept shifts from evaluation tool to design baseline.
The project architect works with the security team to update the security concept for the target architecture. What changes in the risk profile when the system moves to a new platform? What new integration points need protection? What existing controls carry forward, and which need redesigning?
This produces security requirements integrated into the project plan from day one. Network boundaries designed into the architecture. Authentication specified in the technical design. Monitoring planned before deployment, not discovered as a gap during go-live.
The security concept also makes trade-offs visible. When a security requirement conflicts with a technical constraint, that trade-off gets documented as an explicit risk acceptance. The system owner decides whether to accept it. The decision is visible and accountable, not buried in a technical document nobody reads after the project closes.
Governance gates gain substance because they reference a specific document. Does the architecture meet the security requirements? Are controls being built as specified? Does the security concept reflect what we are about to put into production?
Run: where knowledge survives the project
The project team disbands. The implementation partner moves on. Six months later, the operations team is running a system they didn’t build, with monitoring they didn’t design, against risks they weren’t briefed on.
The security concept survives this transition. Maintained through the project lifecycle, it gives operations a current description of the system they are actually responsible for: architecture, risk profile, control landscape, accepted risks, monitoring requirements.
Without it, operations inherits a system and reconstructs the security posture from whatever the project left behind. Rarely complete. Never maintained.
The compound effect
One project doing this properly is an improvement. A portfolio of projects doing it consistently is a different operating model.
When every major initiative maintains the relevant security concept through buy, build, and run, the organisation accumulates current documentation of its actual security posture across critical systems. Audit evidence exists because it was produced as a by-product of doing the work. Risk reporting reflects reality. New projects benefit from predecessors’ work because the baseline is already there.
This replaces the typical pattern where each project creates its own security documentation, disconnected from the system’s history and from every other project touching the same system.
Making it practical
This doesn’t require a transformation programme. It requires one change: include the system security concept in the project initiation checklist.
For existing systems, the current security concept becomes a project input. The project team reviews it at initiation, the security team updates it at design, the project maintains it through build, operations receives it at handover.
For new systems, the security concept is a project deliverable. You have stakeholder attention, budget, and scope definition. Building it during the project is cheaper than afterward, and produces a better result because the people who made the design decisions are still in the room.
For project managers, the ask is straightforward: at each phase gate, the security concept should reflect what the project has decided. If it doesn’t, either the decisions aren’t documented or security wasn’t part of them. Project steering is accountable for delivering within the organisation’s risk appetite. The system security concept is one way to make that accountability concrete and verifiable.
Do the security work the project needs anyway, and the business gets a system that can be securely operated as a by-product, integrated with enterprise security architecture.
This post builds on the System Security Concepts series, which covers the framework from foundation to implementation. If your organisation doesn’t have security concepts for its critical systems yet, the series provides the starting point.
Part of the series: ‘From Paper ISMS to Working Security’
I advise manufacturing companies on security governance and risk management. If this resonates with challenges in your organisation, get in touch.