The NIST Cybersecurity Framework 2.0 provides high-level outcomes for understanding, prioritising and communicating cybersecurity risk. The US Department of Energy's C2M2 assesses capabilities that include information technology and operational technology.[1][2] This report uses these public materials as management references, not mandatory compliance requirements for Chinese enterprises. Framework names do not replace applicable law, industry rules or site procedures.

IT typically focuses on reliable applications, identity, data and platforms, while OT is directly connected to equipment and physical processes. They can share governance objectives without copying each other's operating cadence. An update method suitable for office applications may not suit continuous production. Equally, the site's need for stability should not justify indefinitely avoiding dependency analysis or planned improvement.

Management needs a shared way to frame the problem: if a service is affected, which production or commercial activities suffer, what degradation is acceptable, who may decide and what recovery requires. The discussion then shifts from which class of system matters more to how acceptable business outcomes can be maintained. Technical teams retain specialist judgement, while resource allocation gains a common basis.

ZHICE recommends starting with one critical business service, such as equipment-condition monitoring, production-planning coordination or settlement support. Select it according to actual impact and the clarity of its boundaries, not technical complexity for display. The purpose is to test cross-functional working arrangements, identify responsibility and evidence gaps, and then extend effective practices to other services.

A service dependency view is more than a network diagram. In addition to applications, networks, site equipment and data, include identity authentication, time synchronisation, configuration management, specialist staff, external services and supplier support. A seemingly peripheral shared service may affect several critical activities at once. Departmental asset inventories managed in isolation can easily miss these common dependencies.

Map downwards from the business process, marking owners and evidence status. Each dependency should explain the capability provided, the effect of failure, available alternatives and who can confirm the current position. Label unverified areas as unknown rather than infer that the site operates exactly as shown in an architecture design.

Distinguish dependencies for normal operation from those needed for recovery. An infrequently used system may supply configurations, credentials, installation materials or specialist support during restoration. If those prerequisites depend on the service being restored, circular waiting can result. A tabletop exercise can reveal some issues, but critical prerequisites still need verification within an approved environment and scope.

Detail should serve the decision. Management needs critical services, common dependencies and accountability boundaries; specialists need access to underlying configuration and technical records. Not every detail belongs on one diagram, but important relationships must not disappear merely to simplify the image. Service changes, supplier changes and revised recovery plans should update the view and retain a version history.

NIST's OT security guidance explicitly recognises particular performance, reliability and safety requirements.[3] As of this report's source date, the official NIST publication list identifies Revision 3 as final and Revision 4, issued in 2026, as a draft.[4] This discussion therefore uses the final version for management principles, does not present draft content as an effective requirement and provides no operating instructions for site control systems.

Every change involving IT-OT connections should state its business purpose, impact, dependencies, validation method, implementation window and rollback conditions. The project team explains expected benefits, operations confirms site constraints, and security and technical teams identify new risks. Review may approve implementation, require further validation or change the design, but its basis must be explicit. An approval process should do more than collect signatures.

Change windows should reflect actual business schedules, not simply technical staff availability. Record differences between the test and live environments, including equipment versions, network conditions, load states and external services. Passing a test establishes performance only under the conditions tested; it does not establish safe usability in every site state. Before implementation, specify how differences will be addressed and what still needs observation.

Emergency changes also require executable accountability. Define eligible emergencies, approval authority, temporary-measure records and the timing of subsequent review in advance. Urgency should not erase basic records, while excessive process should not prevent a practical response. Clear routine arrangements make coordination more reliable during exceptions.

Suppliers often hold specialist knowledge, maintenance tools and critical configurations. Partnerships can add capability, but the company must still understand its critical-service dependencies and risks. Contracts should define service scope, response duties, access conditions, knowledge transfer and exit, particularly how acceptable operation will continue after product support ends. 'The manufacturer is responsible' is not an adequate allocation of accountability.

Remote maintenance should be authorised for a defined task, specifying the target, period, owner and necessary records. At completion, confirm whether access has any continuing justification. A long-standing relationship does not replace task-specific boundaries. Conversely, prohibiting all external support may not fit actual operating needs. The governance objective is justified access, traceable activity and confirmed completion.

Asset management should include version, configuration, support status, maintenance responsibility and business ownership. Equipment counts and purchase dates alone cannot support a resilience judgement. For ageing equipment or assets that cannot use routine update methods, record limitations, compensating measures, review dates and an exit path. Risk acceptance needs a basis and an owner; a long-unresolved problem is not automatically an accepted risk.

Supply-chain changes can invalidate recovery arrangements. A new maintenance provider, an expired contract, a departing specialist or discontinued product may make an earlier plan unusable. Include such changes in service review and confirm that the company or an alternative team can obtain the necessary materials, configurations, authorisations and knowledge. Procurement acceptance should test conditions for continued operation, not only installation and a successful functional demonstration.

Business owners and specialists should jointly set recovery objectives, distinguishing recovery time, acceptable data loss, minimum operating capability and post-recovery validation. Targets should not be copied from generic templates or derived solely from today's technical capability. Where business needs exceed available capability, state the gap, temporary arrangements and improvements requiring investment.

A successful backup is one necessary form of evidence, but recovery also depends on configurations, software and hardware conditions, identity permissions, staff knowledge and service sequencing. A backup that cannot be read, complete materials without authorised staff, or a restored system missing an upstream dependency can all prevent business operation. Exercises should therefore cover the complete service rather than merely show that a file opens.

Validation can progress through document checks, tabletop exercises and controlled recovery, with each level stating what has and has not been demonstrated. Live validation must stay within approved scope, environment and safety conditions so the exercise does not disrupt production. Where scenarios cannot be tested on site, retain the evidence limitation and ensure management understands the uncertainty that remains.

After an exercise, record actual time, causes of waiting, coordination, missing information and business checks after restoration. Issues need owners, completion conditions and further review, not just a summary document. A valuable exercise may reveal many problems. Whether those findings lead to continued improvement says more about governance than whether the demonstration went smoothly on the day.

Maturity assessment can expose capability gaps and support discussion, but cannot directly establish the resilience of a critical service. Companies can use public approaches such as C2M2 to inform an improvement register, while connecting each result to a particular service, owner and evidence.[2] A higher score without changes to dependencies, change management or recovery capability does not establish lower business risk.

Observe coverage, execution and validation results together. Coverage identifies critical services with defined dependencies and accountability. Execution shows whether changes, authorisations and handovers follow agreed arrangements. Validation establishes whether recovery objectives are supported under the tested conditions. These answer different questions. Documentation coverage cannot replace actual capability, nor should attention focus only on one exercise result.

Denominators must be explicit. Results depend on whether business owners have confirmed the critical-service inventory, whether change statistics include emergency changes and whether recovery validation distinguishes tabletop discussion from actual operation. List unverified, unreadable and missing-data items separately. Do not remove them from the denominator and claim complete compliance. Assessment should explain residual risk rather than manufacture an attractive completion rate.

Prioritisation should consider business impact, shared dependencies, existing protection and improvement cost together. A high-impact issue that is difficult to resolve may need feasible temporary measures while longer-term work proceeds. An easy fix does not automatically deserve scarce critical resources. Management needs the basis for each choice, reasons for deferral and a review date so funding and staffing can be adjusted over time.

New digital projects should include service dependencies, change review, supplier duties and operational handover in the plan, considering recovery and ongoing maintenance from design. Acceptance should check not only functionality but whether operations has the materials, knowledge and permissions required. Without continuing accountability, a technically complete project can remain an unmanaged transition from the business perspective.

For existing environments, prioritise services with material impact and complex dependencies. Work need not wait for perfectly accurate company-wide asset data, but gaps must be identified. Establish the minimum view that supports a decision, identify shared dependencies and urgent issues, then add detail. A broad inventory exercise that never leads to improvement consumes resources without changing capability.

Every stage should deliver something usable. First define services, responsibilities and principal dependencies. Then address change, access and handover arrangements. Next conduct recovery validation at an appropriate level and close critical findings. Completing a stage does not remove all risk; it supplies evidence for the next decision. Adjust the sequence as business needs change rather than let a fixed roadmap obstruct necessary action.

Budgets should cover ongoing maintenance as well as upgrades. Updating dependency views, reviewing suppliers, managing materials, preparing exercises and closing findings require continuing effort. Funding tools without operational ownership and time allows governance outputs to decay. Include these activities in a plan accepted by business and technical teams, reducing reliance on individual experience and ad hoc coordination.

Joint governance should specify who owns acceptable business outcomes, who performs specialist assessment, who implements improvements and who makes coordinated decisions during an exception. Shared responsibility must not mean everyone is involved but nobody decides. Cross-functional disputes need an escalation path and necessary evidence so material issues reach timely conclusions, retaining dissenting views and limitations.

Management can begin with a real project review or a recovery tabletop exercise and observe whether teams can use the same service view to explain impact, boundaries and responsibility. Unanswered questions should become explicit work items rather than a demand for a more elaborate report. Governance is valuable when it helps teams decide better and continually test whether their decisions work.

IT-OT coordination ultimately requires stable working relationships: identify dependencies together when the business changes, confirm impact together when technology changes, and execute prepared arrangements together during an exception. Tools and frameworks support this process but cannot replace professional judgement or actual validation. Companies should retain understanding and control of critical services and keep them current as organisations, equipment and suppliers change.