Most organizations can show you the control. Fewer can show you that it was engineered: derived from a stated requirement, built into the system, tested, and kept tested as the system changes. The gap between the policy that demands a control and the system that is meant to enforce it is where security engineering works.
Architecture decides which controls a system needs. Operations runs them. Engineering sits between the two. It turns a requirement into a design constraint, builds it, proves it works, and keeps the proof current.
What the standard text says
NIST SP 800-160 Volume 1 Revision 1 (November 2022) defines systems security engineering as a subdiscipline of systems engineering. It applies security principles and methods across the whole system life cycle. Its goal is assured trustworthiness and asset protection despite adversity. The same publication says systems security engineering works with stakeholders so that security objectives, requirements, measures of effectiveness and the methods used to validate them are defined up front.
One footnote matters for every security program. NIST notes that verifying an individual function against its quality and performance attributes helps inform the judgment on system security but is insufficient alone. A firewall that passes its own vendor test has not shown that the system is secure.
Two of NIST’s design principles explain most of what follows. Least privilege: each system element gets the privileges it needs for its specified functions and no more, which limits the impact of failure, corruption or misuse. Defense in depth: loss control should not rely on one defensive element, and the successive barriers should differ in kind, with technical, operational and organizational barriers working together.
Three public cases where the control existed on paper
These cases are documented and public. We use them because each shows a requirement that was stated somewhere and not delivered in the running system. They prove no rate. Public cases over-represent organizations that were investigated.
| Case and source | What the record shows | Engineering gap |
|---|---|---|
Equifax, 2017 US House Oversight majority staff report, December 2018 |
Security policy required critical vulnerabilities to be patched within 48 hours. On 9 March 2017 an alert about the Apache Struts flaw went to about 430 people. A component scan ran on the root directory, not the subdirectory where Struts sat, so it found nothing. An external scan of 958 IP addresses also found no vulnerable instance. Attackers were inside for 76 days. The application needed three databases but its credentials reached 48 unrelated ones. The report says an expired certificate left a traffic-monitoring device inactive for 19 months. GAO reported ten months (report footnote 201). | Our reading: the 48-hour rule was a policy, not a tested mechanism. Both scanners missed the flaw. Application credentials were not limited to the databases the application needed. |
Capital One, 2020 OCC Consent Order 2020-036, signed 5 August 2020 |
The order finds that in or around 2015 the bank failed to establish effective risk assessment processes before moving IT operations to the cloud. It also finds the bank failed to manage risk in the cloud environment, naming the design and implementation of certain network security controls, data loss prevention controls and the dispositioning of alerts. The bank neither admitted nor denied the findings. The penalty was USD 80 million. | Our reading: risk assessment, control design and alert handling are separate gaps in the order's findings, each needing its own owner. |
Target, 2013 US Senate Commerce majority staff report, 26 March 2014 |
The staff report says Target appears to have failed to respond to multiple automated warnings that attackers were installing malware. It also suggests Target did not properly isolate its most sensitive network assets. Caution: the report was built from media reports and expert analysis and uses hedged wording such as appears. | Our reading: detection output with no engineered response path, and weak separation between network zones. |
Our reading: in each case someone could have shown a policy, a tool or an architecture diagram. What was missing was a tested path from requirement to behavior in production.
What the engineering discipline adds
| Activity | Question it answers | Typical failure |
|---|---|---|
| Architecture | Which controls does this system need, and where do they sit? | Diagram approved, never compared with what was built |
| Engineering | Is each control specified as a testable requirement, built, and verified on this system? | Requirement stays in a policy sentence |
| Operations | Is the control running and handled when it alerts? | Alerts raised, nobody owns the response |
Our reading: most organizations fund architecture and operations and assume engineering happens inside them. It usually does not, because nobody is accountable for the hand-off.
Turning a requirement into something testable
A requirement is engineered when you can write the test before the build. Take the Equifax pattern. The policy-style requirement is: restrict access to sensitive data. A testable version is: the service account for application A can authenticate to databases B, C and D and to nothing else.
-
Test: attempt connections from the application host to every other database in the environment. Expected result: all fail. Run it on every change to the application, the account or the network path.
-
Alert: any successful authentication outside the allowed list raises an event with a named owner.
-
Evidence: the last test date and result, stored where an auditor can find it.
This example is Cybrilliant analysis, not a quotation from any standard. It shows the pattern: one sentence of intent, one test, one owner, one date.
Decision
Decision: stop asking whether a control exists. Ask for its requirement, its test, its owner and the date it last passed. Start with the ten controls that guard your most sensitive systems. Any control with no test is an assumption.
What this evidence does not show
Three breaches say nothing about how often control gaps occur. The Target source relies on media reporting. The Capital One order does not name a firewall and we make no firewall claim. NIST publications describe good practice. They do not measure how engineering effort changes breach rates.
A short test
Pick one control your organization reports as in place. Write the requirement it meets, the system that enforces it, the test that proves it, who owns the test, and when it last ran. Add one line: what would tell you if the control silently stopped working. Every blank is a hand-off nobody owns.
Sources
-
NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems, November 2022. Accessed 9 October 2026. nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v1r1.pdf
-
US House Committee on Oversight and Government Reform, Majority Staff Report, The Equifax Data Breach, December 2018. Accessed 9 October 2026. oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf
-
OCC Consent Order No. 2020-036 (Capital One), signed 5 August 2020. Accessed 9 October 2026. occ.gov/static/enforcement-actions/ea2020-036.pdf
-
US Senate Commerce Committee, Majority Staff Report, A Kill Chain Analysis of the 2013 Target Data Breach, 26 March 2014. Accessed 9 October 2026. commerce.senate.gov/wp-content/uploads/media/doc/2014%200325%20Target%20Kill%20Chain%20Analysis.pdf
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionProtect What MattersGuard the identities, data and systems the business depends on.See how we work →Related service
Security Engineering
Use this to find where your control requirements stop being engineered.