Sustainment Focus: Certification is a moment. Sustainment is every day after.

Every organization eventually reaches the same moment. A bank in London, a hospital network, a manufacturer with plants on three continents, a government agency: each one builds a system, tests it, gets it approved, and puts it into production. That moment gets the attention, the budget, and the sign-off. What happens over the next five years usually gets far less.

​

Sustainment and Maintenance is the pillar that governs those five years. Maintenance is the work itself: patching, refreshing components, updating procedures, retraining people. Sustainment is the governance that makes sure the work actually happens, on schedule, with a named owner, and with evidence that it was done, and accepted by every stakeholder.

​

The distinction matters because passing an audit and staying audit-ready are different disciplines. Certification proves a system was sound on one day. Sustainment proves it is still sound today. They need different owners, different budgets, and different rhythms. Programs that treat them as one tend to pass the first review and drift quietly afterward, until the next review finds an organization nobody certified.

​

This article lays out the framework first: how sustainment differs from the pillars around it, Change Management as the oversight for its nine maintenance functions, and the governance and discipline that hold it in place. It closes with a current example of why it matters.

​

Between the Inspections

​

The lesson the story should land is this: readiness is not a state you reach. It is a state you keep, and keeping it takes its own people, its own schedule, and its own authority. An organization that only prepares when an inspection is announced is not ready. It is rehearsing.

Some of the examples in this series go back decades. The tools in them, inspection checklists, paper binders, dumb terminals, and spare parts in lockers, have long since been replaced by dashboards, automated pipelines, cloud platforms, and AI models. That is the point. The technology has changed many times over. The methodology, the governance, the framework, and the discipline have not. An organization keeping an AI platform sound today is answering the same questions a base commander or a trading floor manager answered forty years ago: who owns it, what is the schedule, what changed, did it get integrated correctly, and how do we know it still works?

​

Gate, Rhythm, Response

​

Three pillars in this Framework govern a system after it is built. They are easy to blur together, so it helps to name what makes each one different.

​

               Pillar                                     Tempo                        Triggered by                             Ends in

       4. Test and Evaluation              A gate           A deployment or major change       A one-time sign-off

       6. Sustainment and Maint.        A rhythm       The calendar                                     A recurring report

       7. Incident Response and         A response    Something could not absorb          Recovery and                         Contingency                                                                                                            Lessons learned         

Test and Evaluation asks whether a system is fit to go live. Sustainment asks whether it is still fit today, and next quarter, and three years from now. Incident Response takes over when sustainment detects something its normal cadence cannot handle.

​

The boundary matters in practice. Regression testing after a routine monthly patch belongs to sustainment. Testing a major upgrade or a platform replacement goes back through the Test and Evaluation gate. User Acceptance Testing (UAT) is the endorsement from the end-user. If nobody draws that line in advance, both pillars end up claiming the work or, worse, neither does.

​

Change Management: The Oversight Governance for Maintenance

​

Maintenance needs a single point of oversight, and in this Framework that point is Change Management. Every maintenance action, whether a patch, a component swap, a configuration adjustment, or a procedure update, changes the system that was certified. Change Management is the process that decides which of those changes happen, when, and with what evidence.

​

In practice, that means a standing Change Advisory Board with authority delegated from the Chief Information Officer (CIO), and a consistent path for every change:

​

1. Request. The change is submitted with its purpose, scope, and the systems it touches.

2. Classify. It is assigned a risk level: standard, normal, or emergency. Standard changes are pre-approved and routine. Emergency changes follow criteria defined in advance, never invented under pressure.

3. Approve. The board, or its delegate for standard changes, approves, defers, or rejects it.

4. Schedule. It is placed in an approved maintenance window.

5. Verify. It is tested after implementation and rolled back if it fails.

6. Record. The baseline, documentation, and bill of materials are updated so the record matches reality.

7. ​A change that skips this path is not maintenance. It is drift with good intentions.

​

The Nine Functions Around Change Management

​

Nine maintenance functions surround Change Management. They play three different roles. Five are changes that flow through it. Two are sensors that feed it. Two are enablers that the governance authority supplies so it can run. Keeping those roles distinct matters: a change board approves changes, but it does not set budgets or staffing.

​

Changes: flow through Change Management

​

1. Patch and Vulnerability Management. A routine cadence for patches, plus emergency triggers decided in advance. The emergency exception should already exist on paper before anyone needs it, the same rule that governed the trading floor in the Discipline pillar.

2. Configuration Baseline and Drift Detection. A documented baseline and regular checks that reconcile what the system is against what it is supposed to be. Drift found here goes back to the board to be either approved or reversed. Every undocumented change makes the last audit a little less true.

3. Component Lifecycle and End-of-Life Management. Tracking end-of-life and end-of-support dates at every layer covered in Process Engineering: application, operating system, firmware, hardware, and network. For AI systems, the model and its training data are components too. Refresh is planned and funded years ahead, not discovered when a vendor stops issuing patches.

4. Bill of Materials Currency. A bill of materials is the ingredient list for a system: every component inside it and where each one came from. Software has one (SBOM), hardware has one (HBOM), and AI systems now need one too (AIBOM), covering the models and data they rely on. Each must be updated every time a component changes. A bill of materials that was accurate on the day of certification is a historical document six months later, and an AI bill of materials can go stale even faster, because a model can change underneath you without a new version number.

5. Documentation and SOP Currency. Standard Operating Procedures (SOPs) and RASCI assignments (who is Responsible, Accountable, Supporting, Consulted, and Informed) updated as part of every approved change, not afterward. A procedure written for last year's system trains people to do the wrong thing correctly.​

Sensors: detect problems and feed Change Management

​

  6. Vulnerability and Threat Monitoring. Watching for newly disclosed weaknesses in components                   already deployed. A finding here becomes a change request, and an urgent one triggers the                     emergency path.

  7. Performance and Capacity Monitoring. Treating slowdowns, saturation, and unusual behavior as                early risk signals, not just operations metrics. Degradation is often the first visible symptom of a                compromise, a failing component, or, in an AI system, a model drifting from how it behaved at                    release.

Enablers: supplied by the governance authority

​

  8. Sustainment Planning, Resourcing, and Workforce Currency. Steady-state funding and staffing,                   budgeted separately from the one-time cost of certification, and skills kept in step with the                         environment. This is the sustainment-side partner to the Training and Workforce Development pillar.         A program that funds the audit but not the years after it has already decided to drift.

  9. Sustainment Reporting and Recurring Attestation. A regular report from the Change Advisory Board         and system owners to the CIO and executive leadership, with recurring attestation on a defined               cadence. This is the rhythm counterpart to the one-time sign-off that closes Test and Evaluation: the         same governance function, at a different tempo.

​

The Governance and Discipline That Hold It in Place

​

Change Management and its nine functions describe the work. Governance and discipline decide whether the work survives its first busy quarter.

​

Governance gives sustainment an owner with real authority. Someone must hold the budget, receive the reports, and have the standing to say a system is no longer fit to run. Without that authority, sustainment becomes advice that operations can decline. This is the Governance, Authority and Relationships pillar applied to the years after go-live: decision rights written down in a RASCI, a reporting line that reaches the CIO, and contracts that make vendors part of the rhythm rather than bystanders to it.

​

Discipline keeps the rhythm from bending. The patch cycle runs on schedule even when a release deadline is pressing. The quarterly baseline review happens even when the last three found nothing. Exceptions exist, but they are named in advance, approved by the owner, and recorded, never decided in the moment by whoever finds the cycle inconvenient. This is the Discipline pillar applied to the calendar.

​

The two depend on each other. Governance without discipline produces a sustainment plan nobody follows. Discipline without governance produces hardworking teams with no authority to fix what they find. Organizations that sustain well, in any industry and any country, have both.

​

Sustainment Without a Mandate

The clearest test of whether an organization believes in sustainment is what it does when nobody requires it.

​

Every industry has its certification moment. In retail, it is the payment card compliance assessment. In healthcare, it is the security risk assessment and the accreditation survey. In financial services and insurance, it is the regulatory exam and the annual audit. Each one is a snapshot. None of them, on its own, keeps a system sound in the months between. Regulators set a floor. Sustainment is what an organization does above it, and what it keeps doing when the rules change.

​

The value is easiest to see on a bad day. When a new vulnerability is announced in a widely used component, the organization with a current inventory can answer "are we exposed?" in hours. That holds for a retailer's point-of-sale network, a hospital's connected medical devices, an insurer's claims platform, or a bank's trading systems. The organization without a current inventory spends weeks finding out, and it may find out from an attacker first.

​

The U.S. federal government offers a recent test case. Executive Order 14306 and Office of Management and Budget (OMB) Memorandum M-26-05 removed a mandatory, standardized software attestation that federal vendors had been preparing for, and left each agency to set its own approach. The Discipline pillar covered what that does to vendors. The sustainment question is simpler: if the mandate goes away, does the work stop? It should not, because a current inventory was never valuable because a form required it.

​

The same logic already has a name in security practice. Zero Trust, the model now adopted by governments and enterprises worldwide, rests on the principle that trust is never granted once and assumed forever. It is verified continuously. Sustainment applies that doctrine to the systems and suppliers an organization depends on: a component verified at certification is not verified today unless someone checked again. Same doctrine, different domain.

​

This is the heart of the Framework's Two-Practice Governance Model. Certification Governance owns the point-in-time events: the audit, the accreditation, the authorization to operate, the Test and Evaluation sign-off. Sustainment Governance owns everything between them. Each needs its own owner, because the people rewarded for getting a system approved are rarely the people best positioned to keep it current for the next five years.

​

Stakeholder Responsibilities

Sustainment fails most often through assumption: each party believes someone else is watching. Naming the owners closes that gap.

​

            Stakeholder                                                             Responsibility

CIO / Governance Authority                Funds sustainment as a standing budget line, delegates authority                                                                   to the Change Advisory Board, receives recurring reports, and                                                                       owns the decision to accept, remediate, or retire

Change Advisory Board                       Oversees every maintenance change: classifies risk, approves or                                                                    rejects, schedules windows, and confirms the record matches                                                                        reality afterward

Procurement / Contracting                   

(in government, the Contracting          Writes sustainment obligations into contracts: bill of materials        

Officer and Contracting Officer's         updates, end-of-life notice, and recurring attestation

Representative, or CO/COR)

​

Engineering                                           Maintains the configuration baseline, plans component refresh,                                                                        submits changes to the board, and routes major changes back                                                                        through Test and Evaluation

 

Business Unit / Operations                  Reports performance degradation early and agrees maintenance                                                                   windows in advance

 

Vendors and Suppliers                        Deliver patches and updated bills of materials on schedule, give                                                                     advance end-of-life notice, and flow requirements down to                                                                               subcontractors

 

Support / Help Desk                            Tracks recurring issues as possible early warnings, not isolated                                                                       tickets

 

Data Center / Network Staff                Apply approved changes within the window, monitor capacity, and                                                                detect configuration drift

 

Finance                                                Separates recurring sustainment costs from one-time certification                                                                   costs and protects them from mid-year cuts

​

Compliance / Audit                             Verifies between audits that controls still operate, and tracks every                                                               finding to closure

​

Then and Now

​

Sustainment used to be visible. Someone walked the equipment, checked the logs, swapped the failing part, and signed the binder. The work was slow, but you could see it being done.

 

Today most of it is automated. Patches deploy through pipelines, monitoring tools flag drift, and dashboards report status around the clock. That is real progress, and it creates a new risk: the dashboard can stay green while the program behind it decays. A monitoring tool nobody reviews, an alert rule nobody has updated in two years, or a bill of materials generated automatically but never read is sustainment in appearance only. The technology changed completely. The need for a person who is accountable for the rhythm did not.

 

The AI-Era Parallel

AI systems, from the tools a mid-sized insurer uses to triage claims to the frontier systems some now call super intelligence (SI), make sustainment harder, not easier, because they change in ways traditional software does not. A model is retrained. The data feeding it shifts. A vendor updates the model behind an API without a version number the customer can see. A system that passed every test at release can behave differently six months later with no change anyone approved.

For AI, sustainment means tracking model and data versions as carefully as software versions, re-testing safeguards on a schedule rather than only at release, and reporting drift to the governing authority before an auditor, a regulator, or a customer finds it.

​

A Current Example: Voluntary AI Commitments

A recent example shows how quickly this gap appears, even in well-resourced programs. In September 2026, six frontier AI and chip companies (Anthropic, Google, Meta, OpenAI, Nvidia, and xAI) signed a voluntary accord at the White House on the safety of advanced AI. Each committed to four layers of control: internal controls, an internal oversight team, external audits, and an independent oversight board.

​

Set the policy debate aside and look only at the governance structure. It is a familiar one, close to what regulated industries around the world already use, and it maps cleanly onto this Framework. Internal controls fall under Process Engineering, Test and Evaluation, and Discipline. The oversight team and board fall under Governance. The audits draw on Risk Identification and Test and Evaluation.

​

One layer is missing: sustainment. The commitments describe how controls will be built and how they will be audited, but not who keeps them working between audits as models, staff, and vendors change. That is not a flaw unique to this accord. It is the same gap found in certification programs everywhere, from banking to healthcare to government procurement. External audits can show that controls worked on the day of the audit. Only sustainment can show they worked on every day in between.

 

Sustainment, In Three Sentences

​

Certification proves a system was sound on one day.  Sustainment proves it is still sound today.

 

Sustainment needs its own owner, its own budget, and its own calendar, because work that belongs to everyone in general belongs to no one in particular.

​

And sustainment does not fail loudly. It fails one skipped patch, one stale procedure, and one unread report at a time, until the next audit discovers an organization nobody certified.

​

The Failure Mode

The failure mode is not neglect. It is success. A system passes its audit, the team that built it moves to the next project, the budget line closes, and everyone assumes the controls will hold themselves in place. They do not. Every system is drifting from its certified state the day after certification. The only question is whether anyone is measuring the drift.

​

Where This Leads

Sustainment is the sixth pillar in the IT Risk and Cybersecurity Governance Framework because it is what keeps the first five true over time. Governance assigns the authority, Risk Identification names what matters, Process Engineering builds the controls, Test and Evaluation proves they work, and Discipline holds the rules in place. Sustainment makes sure all of that is still accurate on an ordinary Tuesday three years later.
 

When the rhythm detects something it cannot absorb, a compromised supplier, a failure no patch can fix, a vulnerability already being exploited, the work moves from sustainment to response. That is the subject of Pillar 7, Incident Response and Contingency.

 

This is Pillar 6 of 8 in the IT Risk and Cybersecurity Governance Framework series. Read the full Framework at MVWConsultants.com/framework.