When I took over Enterprise IT Contracts at the Department of Justice, there was no shortage of activity. Vendors were onboarded, services were procured, systems were deployed. What there wasn't was a process. Every category of technology, applications, infrastructure, telecom, hardware refresh, ran through whatever workflow the person handling it that week happened to improvise. Nothing was wrong in any single instance. The problem was that nothing was repeatable, nothing was defensible under audit, and nobody could tell you in advance what a request would require before it hit their desk.

That's the moment Process Engineering earns its place as its own pillar, separate from Risk Identification and Classification before it. Identification and classification tell you what you're looking at and how serious it is. Process Engineering is what you do next: design the actual mechanism, the steps, the approvals, the stakeholders, the sequencing, that turns a classified risk or a planned change into something executed correctly and consistently. Skip this step and you're left running every request through instinct, which doesn't scale and doesn't survive an audit.

Engineering has become one of the most important disciplines in today's environment, because the vulnerabilities sitting inside modern infrastructure are enormous and growing with every layer added. Artificial intelligence is still in its infancy, and while it offers real opportunity to improve process and procedure, that same immaturity creates enormous exposure, to counterfeit components, fraud, and hacking, that a mature discipline hasn't yet had time to close. An engineered process is what stands between that opportunity and that exposure.

Building the Vendor Management Office

Standing up DOJ's IT Vendor Management Office and Service Broker Acquisition Strategy meant building a process where none existed, across categories that didn't behave the same way. A software license renewal, a telecom circuit change, and a hardware refresh all needed governance, but they didn't need the same governance. The first version of the process tried to treat them alike, and it broke almost immediately: telecom changes needed carrier lead times and outage windows that a software renewal never touched, and hardware refresh cycles were driven by procurement lead times that had nothing to do with either one. The process had to be engineered around what each category actually required, not standardized for administrative convenience.

That's the core lesson of this pillar, and it holds whether you're looking at enterprise contracts or the technical layers underneath a single system. One process does not fit every layer.

The Layers Underneath

Even without getting into technical detail, it's worth naming the layers explicitly, because each one carries a different process and a different stakeholder relationship.

Applications sit closest to the business. Change here is driven by business requirements, and the process has to accommodate a change advisory board, user acceptance input, and a timeline the business unit has a real say in. The relationship is with the business, not just with IT.

Operating systems are more of an internal IT discipline. Patch cadence is dictated partly by the vendor's release schedule and partly by your own testing window. The relationship here is largely internal, but it's still paced by someone else's calendar.

Firmware is the layer everyone forgets exists until it fails. It's vendor-controlled, often opaque, and difficult to test in advance. At DHS CWMD, a mobile device firmware risk finding drove a program-wide remediation effort, precisely because nobody had engineered a distinct process for firmware. It had been getting swept into the same review cycle as the operating system layer above it, and that cycle wasn't built to catch what firmware actually needed.

Hardware runs on procurement timelines and physical logistics. The relationship of record is with original equipment manufacturers and vendor management, and the process has to accommodate refresh cycles that are measured in months, not days.

Network is usually the least forgiving layer. Carrier relationships, service level agreements, and outage windows drive the process, and downtime here tends to be felt immediately and broadly.

The Thread That Runs Through Every Layer

Security controls, third-party component risk, and compliance with Executive Orders 14028 and 14306 aren't a sixth layer sitting beside the other five. They're a thread that runs through all of them, and what that thread requires changes depending on which layer it's crossing. At the application layer, it shows up as access control and secure development practices. At the operating system layer, it's patch compliance against federal vulnerability disclosure timelines. At the firmware layer, it's the third-party component risk that's hardest to see and hardest to verify, which is exactly what the CWMD finding exposed. At the hardware layer, it's country-of-origin and supply chain provenance, the same territory GSA's Section 889 Prohibited Equipment Committee was built to police. At the network layer, it's carrier-level security controls and telecom supply chain integrity.

Engineering a process that ignores this thread produces a workflow that looks complete on paper and fails the first time an auditor, or an incident, asks where a component actually came from.

Open-source software is where this thread gets hardest to hold, because the assumption behind an attestation, a single accountable party willing to sign something and stand behind it, often doesn't exist. A commercial vendor can attest to what they shipped. An open source dependency might come from one volunteer, a loose community, or a well-governed corporate-backed project, and from a dependency list those look identical. You frequently cannot tell who built it, what security practices they follow, or whether anyone is still maintaining it, until something breaks and you go looking. This is also where the Contracting Officer and Contracting Officer's Representative have nowhere obvious to point: there is no vendor equivalent to call for an open source project, so accountability has to shift to whoever incorporated the dependency into a deliverable, the system integrator or prime contractor, who becomes the party the CO/COR holds responsible for the SBOM and risk assessment on that component, not the open source maintainers themselves. Process Engineering's job here isn't to demand an attestation that isn't available, it's to engineer the process for getting whatever assurance actually is obtainable: verifying how a package was built rather than trusting it as delivered, tracking maintainer activity and responsiveness as a standing signal rather than a one-time check, generating a software bill of materials yourself at the point you pull a dependency in since the upstream project usually won't hand you one, and scanning continuously against known vulnerability databases rather than only at intake. None of that produces the certainty a vendor attestation does. It produces the next best thing, and engineering that "next best thing" deliberately is the difference between an organization that knows its exposure and one that discovers it during an incident.

Performance and Integration Belong Here, Not Later

Performance requirements and integration and change management aren't separate topics bolted onto process engineering. They're part of what "engineered correctly" means. A process that doesn't account for performance targets, dependency mapping, sequencing across layers, and a rollback plan isn't finished, it's just untested. If a system's first real performance data shows up during Test and Evaluation, the engineering work was incomplete going in. Test and Evaluation exists to validate a design, not to discover for the first time whether that design works.

Engineering Doesn't End at Deployment

Process Engineering also owns the tiered support model that stands behind whatever gets deployed, Tier 1 triage, Tier 2 specialist escalation, and Tier 3 engineering. That third tier is where the process comes back to its own designers. When a help desk can't resolve an issue and a specialist can't either, it lands with the people who engineered the underlying process or system in the first place, because at that point the fix isn't a known procedure, it's a design problem.

This closes the loop rather than opening a new topic. A support model where Tier 3 is constantly fielding escalations isn't a staffing problem, it's a signal that the original engineering, the layer-specific process, the security and compliance thread, the performance target, didn't hold up in production. Tier 3 volume is one of the more honest measures of whether a process was actually engineered well or just assembled well enough to pass initial deployment.

That's the handoff line for this pillar. Process Engineering owns everything up through a fully designed change: the layer-specific workflow, the security and compliance thread running across it, the performance target, the integration and rollback plan, and the Tier 3 capability standing behind it once it's live. Once that design exists, it moves to Pillar 4 for Test and Evaluation. Engineering builds it right. T&E proves it.

The Present-Day Version of the Same Problem

Organizations adopting AI tools today are running the same experiment DOJ ran with vendor management before the office existed, and CWMD ran with firmware before the finding forced a fix: improvising a process because a formal one hasn't caught up yet. AI systems cut across the same layers, application-level tools, the infrastructure they run on, the third-party models and components underneath them, and most organizations are governing all of it with whatever ad hoc review happens to be in place, rather than an engineered process built for how AI actually behaves at each layer. The lesson from Process Engineering is the same one it's always been: build the process to fit what you're governing, or the gaps will find you eventually.

This is the third article in an eight-part series on the IT Risk and Cybersecurity Governance Framework. Pillar 3 of 8: Process Engineering.