IT System Criticality: a practical management guide

What to do in practice

A digital initiative should first be framed as a management decision: define the object, data, constraints, action owner and verification method. Technology selection follows that framing. For this task, the initial evidence is “migration has no rollback scenario”, and the decision boundary concerns infrastructure and security controls.

The practical focus is service resilience, transparent dependencies and a governed platform lifecycle. A decision is ready for approval when the object, owner, baseline, permitted action and outcome evidence are explicit; the reference object in this article is business services and criticality.

Criticality, resilience and the regulatory boundary

Business services and dependencies are classified before resilience controls are selected. For objects that fall within the scope of Federal Law No. 187-FZ on critical information infrastructure security, applicable requirements are recorded separately and mapped to versions, migrations and operations.

The architecture map includes the service owner, tolerated downtime, data, integrations, infrastructure components, controls and recovery scenario. For the signal “a component cannot be replaced in isolation”, resilience is tested across an end-to-end service rather than an isolated server.

Checks before the project

The work starts with an observable situation, not with interface selection. The diagnostic signal for this article is: migration has no rollback scenario. It should be supported by a real example such as a document, data sample, decision record or registered variance.

The first scope is limited to one object and one decision. Changing every process, master-data set and system at once obscures causality. For the signal “a component cannot be replaced in isolation”, a representative boundary is a period, business unit or transaction class where the situation can be tested again.

• Signal: Dependencies are known only to individual specialists. Evidence includes an example, frequency and consequence for integrations and data flows.
• Event to test: a component cannot be replaced in isolation. Evidence shows timing, frequency and consequence for infrastructure and security controls.
• Indicator: There is no criticality classification. Analysis needs an actual example and the resulting change in versions, migrations and operations.

Objects, identifiers and owners

Describe the boundary through object records rather than system names. For infrastructure and security controls, record meaning, identifier, source, quality owner and update event; for versions, migrations and operations, also document the relationship rule.

Test the link between infrastructure and security controls and versions, migrations and operations using an end-to-end example. The team performs “frame the problem”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Boundary 1. Object: Business services and criticality. Define the source, frequency, permitted transformations and response to “there is no criticality classification”.
• Object 2: Applications and components. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Integrations have no owners.
• Subject area 3: Integrations and data flows. Verification basis: system of record, owner authority and the signal “migration has no rollback scenario”.

Decision and supporting evidence

State the decision before compiling requirements. It identifies business services and criticality, the role authorised to choose, the permitted action and the evidence participants will use to accept or reject an option.

Do not combine the signal “migration has no rollback scenario” and the risk “selecting a platform without a dependency map” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “assign roles and actions” connects them in a testable scenario.

• Decision 1: object — business services and criticality; signal — integrations have no owners; action — assign roles and actions.
• Decision 2: object — applications and components; signal — migration has no rollback scenario; action — verify the outcome.
• Decision 3: object — integrations and data flows; signal — dependencies are known only to individual specialists; action — frame the problem.

A practical decision model

The method is a sequence of decisions rather than a universal checklist. For versions, migrations and operations, each output is used at the next step: the model supports the scenario, the scenario defines data and requirements, and requirements become test and acceptance criteria.

For infrastructure and security controls, the sequence may change with scale and constraints, but assumptions are always documented. When source data is incomplete or a decision involves an external party, the dependency receives an owner, review date and condition for proceeding. The first action is “assign roles and actions”.

• Step 1. Frame the problem. Output: integrations and data flows.
• Identify the management object is the action at stage 2. The output documents infrastructure and security controls.
• At position 3, the action is “assemble data and constraints”; its result is versions, migrations and operations.
• Stage 4: assign roles and actions. The working artefact describes business services and criticality.

Sources and integrations

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is versions, migrations and operations.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “migration has no rollback scenario”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Control record 5. Object: Versions, migrations and operations. Observable signal: A component cannot be replaced in isolation. Accountability: semantic owner and quality owner.
• Record 4. Object: Infrastructure and security controls. Required details: identifier, lineage, quality rule and update event. Signal: Dependencies are known only to individual specialists.
• Subject area 3: Integrations and data flows. Verification basis: system of record, owner authority and the signal “migration has no rollback scenario”.

Roles in the operating environment

For business services and criticality, the role model determines more than screen access. In the action “assign roles and actions”, it identifies who changes a rule, authorises an exception, accepts risk and confirms the outcome. The accountability matrix is tied to decisions and artefacts rather than abstract departmental participation.

A business–IT disagreement is resolved by the decision owner using agreed evidence. The architect does not replace the business owner, and the project manager does not define the meaning of a measure. For business services and criticality, this separation is especially important because of the risk “a shared component becoming a new failure point”.

• Business owner: decision area — integrations and data flows; control action — assign roles and actions.
• Architect is accountable for infrastructure and security controls and confirms the action “verify the outcome”.
• Role: Data owner. Decision object: versions, migrations and operations; verified step: frame the problem.
• Project manager decides within business services and criticality; the basis is prepared through “identify the management object”.

How to verify the change

Verification of business services and criticality starts with the baseline. The sample, period, calculation rule, known exceptions and interpretation owner are preserved. After the change, the same scenario is repeated under comparable conditions; a new method or data population is documented as a separate version.

A functioning feature is not yet acceptance evidence. A user must receive the signal “migration has no rollback scenario” from the agreed source, understand its lineage, make an authorised decision, execute the action through the working environment and observe confirmed actuals for infrastructure and security controls.

• Criterion 1: Business services and criticality; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Migration has no rollback scenario.
• Criterion 2. Object: Applications and components. Test fields: baseline, target change, source and owner. Signal: Dependencies are known only to individual specialists.
• 3. Acceptance object: integrations and data flows; compare the baseline sample, expected change and confirmed actuals. Test signal: A component cannot be replaced in isolation.
• Evidence item 4 describes infrastructure and security controls, comparable test conditions and the person accountable for interpretation. Signal: There is no criticality classification.

Decision risks

For the risk “selecting a platform without a dependency map”, define an observable condition and control decision. The record also includes the owner, response time, execution evidence and rollback rule if the control fails.

Verify the regulatory basis against an official source and current version. Map it to versions, migrations and operations in a requirement–process–data–control matrix and assign an owner for interpretation.

• Risk: Selecting a platform without a dependency map. Control: assemble data and constraints. Evidence: versions, migrations and operations.
• Risk condition 2: Claiming compatibility without testing. Response: Assign roles and actions. Testable evidence: Business services and criticality.
• The risk scenario “a shared component becoming a new failure point” is addressed through “verify the outcome” and confirmed using applications and components.
• Controlled constraint: transition without operational criteria. The owner performs “frame the problem” and provides integrations and data flows.

Pack for the first decision

The first session examines one real case involving infrastructure and security controls. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “migration has no rollback scenario”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “assign roles and actions”; assign an additional test or stop condition to the risk “a shared component becoming a new failure point”.

• Step 1. Frame the problem. Output: integrations and data flows.
• Identify the management object is the action at stage 2. The output documents infrastructure and security controls.
• Evidence item 4 describes infrastructure and security controls, comparable test conditions and the person accountable for interpretation. Signal: There is no criticality classification.
• Test 5 concerns versions, migrations and operations. The method, interpretation owner and outcome source are documented. Signal: Integrations have no owners.