The Risk Process That Decides What Your SCIF Actually Costs
- Phil
- Jun 9
- 3 min read
There is a step in every ICD 705 project that teams quietly skip. It looks like paperwork. It comes early, before the design is interesting, and the document it produces is short. Most teams hand it to the security lead and move on.
That step is the analytical risk management process. It decides more about the final cost, schedule, and configuration of the project than any other single activity. Skipping it has consequences. Doing it well has compounding payoffs.
The process has four core elements: threat analysis, vulnerability analysis, probability analysis, and consequence analysis. The threat analysis asks who or what is positioned to compromise the facility, the information inside, or the people working there. The vulnerability analysis asks how those threats could actually succeed given the current and planned conditions. The probability analysis asks how likely a successful compromise is. The consequence analysis asks what would happen if compromise occurred.
The output is not a long report. It is a documented set of decisions, each one tied to a specific risk picture, that justifies why the construction and operational measures for this particular SCIF look the way they do. The AO and the SSM are the primary owners of this work, and the AO is the one whose signature ultimately accepts the residual risk.
The IC Tech Spec is explicit about timing. Security begins the moment a SCIF requirement is identified. Not when drawings are issued. Not when the contract is let. The moment the requirement exists, the risk picture matters, and decisions made before the risk picture is documented are decisions made without justification.
Two practical consequences flow from that.
First, the analytical risk management process is the only mechanism in the standard that allows requirements to be reduced. The baseline construction standards in the IC Tech Spec assume a generic risk picture. If the actual risk picture for your project is lower, because the surrounding security in depth is strong, because the threat environment is benign, or because the consequence of compromise is bounded, the standard allows specific requirements to be mitigated. That is not a loophole. It is how the standard is designed to work. But the mitigation only stands if the risk-based justification is documented. Build a SCIF without that documentation and every later reviewer will hold you to the baseline, even when the baseline is overkill.
Second, the process also allows requirements to be enhanced. When the threat picture is higher than the baseline assumes, or the consequence of compromise is more severe than baseline, the AO has the basis to require countermeasures beyond what the IC Tech Spec specifies. Both directions work for the same reason: the standard wants the protection to fit the actual risk, not to default to a number on a page.
This is also where the standard becomes the defense against fraud, waste, and abuse. Every security decision on the project has to carry a documented risk-based justification. A vendor cannot show up and sell a $40,000 door upgrade because the door upgrade “exceeds the standard.” Either the risk picture supports the upgrade or it does not. A subcontractor cannot quietly downgrade an assembly to save labor because “this should still meet the standard.” Either the documented risk picture allows the change or it does not. The discipline is what keeps the project honest in both directions.
A common pitfall worth flagging: pre-certification claims. Vendors selling SCIF-relevant products will sometimes say their door, window, panel, or kit is “pre-certified to ICD 705” or “approved for SCIF use.” That phrasing is misleading. ICD 705 does not pre-certify products. The IC Tech Spec defines test methods and performance criteria. The AO is the one who decides whether a specific product, installed in a specific way, in a specific context, meets the standard for this project. Vendors who understand the standard will show you the test reports and let your AO make the call. Vendors who promise blanket pre-certification are usually overstating their position.
The teams that get this right treat the risk management process as the front end of the entire project, not as a security deliverable that lives off to the side. They start it the day the requirement is identified. They use it to drive category decisions, construction method decisions, and budget assumptions. They re-run it whenever the project conditions change. By the time the design is issued for construction, the risk justification for every consequential choice is already on paper.
Done that way, the process is not paperwork. It is the document that explains why every other document looks the way it does. Done badly, the project pays for it later, usually at the AO review or at the accreditation walkthrough, when there is no time left and no leverage to renegotiate.
This material is taught at greater depth in Module 4 of the ICD 705 Foundations Series. The full Series is available at psc-consultant.com/on-demand-education.
Comments