Long before a single camera is mounted or a barrier is installed, an industrial project regulated by the Supreme Authority for Industrial Security (SAIS) is already being shaped by one thing: how well its risks have been understood. Most project owners assume that understanding is already in place. Fewer can demonstrate it when the regulator asks for the reasoning behind their design.
That reasoning has a source, and it is not the design drawings. It is the Security Risk Assessment (SRA) the security study that must come before any physical security design is developed. The SRA establishes the security basis of the project: the facility, its purpose, its operating environment, its critical assets, the surrounding area, the expected threat conditions, the vulnerabilities that may expose the site, and the consequences that could follow a security event. Everything that comes afterward either rests on this foundation or inherits its weaknesses.
Where the SRA Sits in the Qualification Process
Projects under SAIS jurisdiction move through a structured qualification pathway of four stages. Each stage must be documented, submitted, and approved before the next can begin, and no construction, procurement, or installation of security infrastructure is permitted until the required approvals are secured. This sequence is the backbone of qualifying any project subject to SAIS instructions.
The first stage carries a weight that many owners underestimate. The Security Risk Assessment and Concept of Design does not simply open the process; it sets the terms for everything that comes after it. The designs, specifications, budgets, and approvals of the later stages all trace back to the conclusions drawn here. When the assessment is sound, the stages that follow have something reliable to build on. When it is weak, that weakness travels downstream into every decision the project makes.
A design that begins with cameras, gates, barriers, access-control devices, and control rooms may look complete on paper. The real question is whether those measures respond to the actual risk conditions of the project. The SRA is what answers that question, which is why it deserves to be treated not as one step among several, but as the stage that gives the others their value.
When the Foundation Is Wrong, Everyone Pays Later
Consider a sequence that plays out more often than most owners would like to admit. A project moves quickly into design and procurement on the strength of an assessment that was treated as a formality. Equipment is specified, budgets are committed, and the submission goes to the regulator. It comes back rejected. The facility was misclassified, key threats were never properly analyzed, and the countermeasures no longer match the risk. Now the design has to be reworked, some of the purchased equipment no longer fits the corrected requirements, timelines slip, and costs that were never budgeted appear on the owner's desk.
Nothing in that outcome was caused by the later stages. It was decided at the first one. The rejection, the rework, and the wasted spend were built into the project the moment a weak assessment was accepted as good enough.
The Surrounding Area Is Part of the Risk Picture
A regulated facility cannot be assessed from inside the plot boundary alone. The location of the project, the surrounding land use, nearby facilities, access roads, logistics routes, adjacent industrial activities, public interfaces, vacant land, utilities, and external movement patterns can all influence the security exposure of the site.
For a project manager or owner, this is not a theoretical concern. A facility may have a well-designed internal layout and still remain exposed because of an uncontrolled approach road, an overlooked adjacent activity, a poorly understood external interface, or a surrounding condition that was never examined during the study phase. A proper SRA therefore looks at both the project and the area around it, with the aim of understanding how the site may be approached, what may affect it from outside, which parts of the facility are more exposed, and how external conditions could influence security, safety, and continuity of operations.
Threats, Risks, and Vulnerabilities Are Not the Same Thing
One of the clearest markers of a serious assessment is that it distinguishes precisely between three terms that are often used loosely.
A threat is a possible source of harm to the facility. It may arise from unauthorized access, sabotage, criminal activity, insider misuse, civil disturbance, hostile intent, operational disruption, or other conditions relevant to the site and its surroundings.
A risk is the assessed significance of that threat to the project. It weighs the likelihood of occurrence, the potential consequences, and the effect on people, assets, operations, safety, and continuity.
A vulnerability is a weakness that may allow a threat to reach the facility. It can exist in the perimeter, access routes, site layout, visibility, procedures, staffing, systems, response arrangements, or the interface between the facility and its external environment.
These elements only become useful when they are analyzed together. A list of threats on its own gives designers nothing to work with. A risk rating without an understanding of vulnerabilities does not explain how an event could actually unfold. And a vulnerability assessment without threat context can produce measures that are technically correct but disconnected from the facility's real exposure. The value of the SRA lies in bringing the three together into a single, coherent picture.
How the SRA Connects Classification to Defense in Depth
Serious industrial protection has never relied on one wall or one system. It works through coordinated layers, site perimeter, controlled access points, security zoning, surveillance coverage, intrusion detection, security lighting, barriers, control-room operations, response arrangements, guard deployment, and operating procedures, each reinforcing the others so that a breach in one does not expose the asset. This is the principle of Defense in Depth, and it is central to how SAIS expects facilities to be protected.
Those layers only work when they are proportionate to the actual threat, and proportionality is where classification enters. The Business Criteria Analysis (BCA) and Facility Security Classification (FSC) establish the regulatory level of protection expected for the facility. The SRA then explains how that level should be applied to the specific project site by analyzing threats, risks, vulnerabilities, and credible security scenarios.
This is the practical link between classification and design. The BCA and FSC identify the level of security SAIS expects. The SRA converts that level into a project-specific protection logic. Physical security design then translates that logic into systems, infrastructure, manpower, and operational procedures. Defense in depth is not achieved by adding more equipment to the drawings; it is achieved when the right layers are applied at the right locations, for the right risks, and at a level consistent with the approved classification of the facility. Protecting beyond that level wastes capital. Protecting below it leaves the asset exposed.
Security Scenarios Turn Analysis Into Decisions
An assessment becomes genuinely useful when its analysis is translated into credible security scenarios. A scenario explains how a security event could affect the site by connecting the threat source, the vulnerable condition, the affected asset, the possible method of occurrence, and the expected consequence. It allows the project team to understand what may happen, where, how it could develop, and what the impact on the facility would be.
This step is what gives design its reasoning. Scenarios explain why an access point requires control, why a particular boundary needs a specific level of protection, why a certain area requires surveillance, why a control room must support particular functions, and why certain procedures must be in place before the facility becomes operational. Without scenarios, security design tends to become a technical layout. With them, it becomes a deliberate response to defined security events.
Countermeasures Must Cover Systems, Manpower, and Plans
The SRA should lead to countermeasures suited to the facility's risk profile and approved classification, and those countermeasures have two sides that must be addressed together.
The first is physical: perimeter protection, access control, video surveillance, intrusion detection, barriers, gates, lighting, communications, and control-room systems. The second is human and operational: manpower requirements, guard posts, patrol arrangements, control-room staffing, visitor and contractor control, vehicle-screening procedures, emergency response measures, escalation arrangements, and the security plans required to run the facility in a controlled and compliant manner.
A facility is not protected by equipment alone. Systems need people to operate them, procedures to govern their use, supervision to maintain discipline, and response arrangements to manage incidents when they occur. For this reason, the SRA must define countermeasures in a form that can be carried directly into design requirements, staffing assumptions, and operational security plans. Countermeasures assembled without this analysis behind them are not a security plan in any meaningful sense; they are a costly assumption. The SRA replaces that assumption with a design that can be defended, both operationally and before the regulator.
Why Security Design Must Follow the SRA, Not Precede It
Once the SRA has established the threat, risk, vulnerability, scenario, and countermeasure basis, physical security design can proceed on defensible ground. Perimeter strategy, access-control philosophy, security zoning, surveillance coverage, intrusion detection, control-room requirements, guard deployment, system infrastructure, emergency interfaces, and operational procedures should all connect back to the risk basis the assessment established.
A drawing that shows cameras, gates, readers, barriers, and control rooms is not automatically a sound security design. It becomes credible only when the project team can explain why each measure is required, what risk it addresses, how it supports the protection layers, and how it aligns with the approved facility classification. The SRA is what supplies that reasoning. Without it, a project can produce drawings that look detailed yet cannot justify the measures they propose for a SAIS-regulated facility.
Why This Cannot Be a Desktop Exercise
An assessment that satisfies SAIS requirements is not a form to complete or a checklist to tick. It calls for a security team capable of understanding the project, reading the surrounding area, identifying credible threats, assessing vulnerabilities, evaluating consequences, developing realistic scenarios, and defining countermeasures that designers, contractors, operators, and reviewers can actually use.
This is where a qualified security consultant becomes essential. The consultant is expected to deliver more than a report. The work is to establish the security reasoning that lets the owner, project manager, designer, contractor, and operator proceed from a clear and defensible basis. When this is done well, the effect on the project is tangible: approvals are reached more efficiently, protection is proportionate to real risk, capital is directed where it counts, and the facility ends up genuinely secure rather than merely compliant on paper. When it is improvised, the project absorbs the cost in rejected submissions, lost time, wasted spending, and exposure that tends to surface at the worst possible moment.
The SASECON Approach
At Saudi Ansary Security Consultancy LLC (SASECON), we treat the Security Risk Assessment as the foundation of physical security design and operational security requirements for SAIS-regulated projects.
Our work begins by understanding the facility, its approved classification, the surrounding area, the project function, the critical assets, the operational interfaces, and the relevant threat environment. From there, we analyze threats, risks, and vulnerabilities, develop credible security scenarios, and define the countermeasures the facility requires, its security systems, manpower, guard deployment, control-room operations, response arrangements, and security plans. The protection strategy is ours to establish and ours to defend before the regulator: proportionate to the assessed risk, and aligned with SAIS expectations.
Every project under SAIS oversight will eventually be secured in one way or another. The difference lies in whether it is secured on a foundation strong enough to carry the cost, the timeline, and the risk that depend on it. Before your project moves into design and procurement, it is worth asking a simple question: if the regulator challenged the reasoning behind your security design tomorrow, would it stand on its own, or would it have to be rebuilt after the budget has already been committed?
