How do we include new digital platforms in our ISMS scope?

Including new digital platforms in your Information Security Management System (ISMS) scope is a change-control exercise, not just paperwork. You are expanding the system boundary that your policies, controls, and audits must cover. In regulated manufacturing, this needs to be deliberate, traceable, and validated.

1. Confirm the platform is in scope for the ISMS

Start by deciding if the new platform should fall under your existing ISMS at all:

• Business purpose: What processes will it support (e.g., batch records, deviation management, maintenance, engineering change, training, supplier management)?
• Information types: Will it handle controlled technical data, QMS records, MES data, personal data, or export-controlled information?
• Regulatory relevance: Does it touch product quality, safety-related data, regulated records, or evidence used in audits?
• Operational criticality: Would loss or compromise of this platform materially affect production, quality, or compliance?

If the answer to any of these is yes, the platform belongs within your ISMS scope, even if it is a cloud service or externally hosted.

2. Define the scope boundaries explicitly

ISMS scope creep and ambiguity are common in brownfield environments. Document boundaries clearly:

• Organizational scope: Which plants, business units, and roles will use the platform?
• Process scope: Which procedures, work instructions, and records will move to or depend on the platform?
• Asset scope: List the platform itself (SaaS, on-prem), supporting infrastructure, and dependent legacy systems.
• Interfaces: Identify connections to MES, ERP, QMS, PLM, historian, OT networks, identity providers, and file shares.

This scoping step should feed directly into your ISMS scope statement and your asset inventory or configuration management database.

3. Classify information and determine protection needs

Before finalizing ISMS coverage, classify what the platform will store or process:

• Confidentiality: E.g., trade secrets, ITAR/EAR or similar export-controlled data, customer IP, personally identifiable information.
• Integrity: Batch records, device history records, inspection data, calibration data, maintenance logs, CAPA records.
• Availability: Impact of downtime on production, release, maintenance, or certification activities.

Use your existing classification scheme. This will drive which ISMS controls and regulatory controls need to extend to the new platform.

4. Integrate with risk assessment and treatment

The platform cannot be “in scope” in a meaningful way until it is included in your risk management process:

• Identify risks: Include vendor risk, cloud/hosting risk, integration risk with legacy systems, and OT/IT boundary risks.
• Consider regulated impacts: Loss of data needed for audits, incomplete traceability, uncontrolled changes to validated processes, or loss of evidence for release decisions.
• Evaluate existing vs new controls: Determine what is covered by corporate controls and what must be platform-specific (e.g., logging, data retention, backup/restore, change control, access management).
• Document risk treatment: Link risks and controls in your risk register, including accepted risks and residual risk justification.

In most environments, this is done using your existing ISMS risk methodology. The key is to treat the platform as another asset in that system, not as an exception.

5. Update the Statement of Applicability and control mappings

Including a platform in scope normally requires updating your Statement of Applicability (SoA) and related mappings:

• Identify applicable controls: For example, access control, cryptography, logging and monitoring, supplier relationships, business continuity, and system acquisition and development controls.
• Map responsibilities: Separate what is managed by the platform provider from what is your responsibility (e.g., identity, key management, configuration, network segmentation).
• Extend existing standards: If you have standard baselines for servers, applications, or OT interfaces, adapt and extend them for this platform.

Where you rely on a vendor’s controls, ensure evidence and contractual terms exist to support that reliance, especially for regulated data and auditability.

6. Establish governance, ownership, and change control

Many issues come from unclear ownership, especially where manufacturing, IT, OT, and quality all touch the same system:

• Assign system ownership: Define a system owner (often in operations or quality) and a technical owner (often in IT/OT).
• Define decision rights: Who approves configuration changes, new integrations, or use of new modules?
• Align with validation and qualification: For GxP or aerospace-grade environments, tie ISMS change control to validation/change management so security changes and functional changes stay synchronized.
• Set lifecycle expectations: Consider that OT and core manufacturing platforms may be in place 10–20 years; ensure governance is sustainable.

Without this, platforms end up half-in, half-out of ISMS scope, which creates audit and security gaps.

7. Integrate with brownfield and legacy systems

In real plants, the new platform must coexist with a mix of legacy MES, ERP, QMS, and custom tools rather than replacing them outright:

• Document integration points: Interfaces to legacy systems, data exports/imports, shared IDs and roles, and shared infrastructure.
• Manage double-system risk: When records or workflows exist in both old and new systems, define which is authoritative and how inconsistencies are detected and resolved.
• Handle phased adoption: If rollout is staged by line, product, or plant, the ISMS scope and risk treatment must reflect that transitional state, not just the “future-state” architecture.
• Coordinate with OT security: Where the platform touches OT networks (e.g., collecting data from PLCs or machines), harmonize with existing network segmentation, remote access policies, and any IEC 62443-aligned controls.

Full replacement of established systems often fails or gets deferred in regulated plants due to qualification burden, integration complexity, and downtime risk. Your ISMS needs to recognize and manage this coexistence instead of assuming a clean slate.

8. Verify implementation and evidence for audits

For the platform to be practically “in scope,” you must be able to demonstrate controls and their effectiveness:

• Technical verification: Confirm access controls, encryption, logging, backup/restore, and configuration baselines work as documented.
• Process verification: Ensure joiner/mover/leaver processes, change control, incident response, and vendor management processes cover the platform.
• Evidence collection: Define how you will produce logs, change records, risk assessments, and validation documentation during internal and external audits.
• Testing in regulated contexts: Where the platform supports qualified/validated processes, ensure security-relevant changes are evaluated under change control, and that testing does not compromise production or compliance.

This step often uncovers gaps that need closure before you can credibly claim the platform is fully integrated into the ISMS scope.

9. Reflect the new platform in policies, procedures, and training

Finally, update the human and procedural side:

• Policies and standards: Ensure they explicitly cover cloud/SaaS or the specific platform category, not just generic on-prem systems.
• Procedures and work instructions: Update operational, quality, and engineering procedures that now depend on or interact with the platform.
• Training: Train relevant staff on secure use, data handling in the platform, and how it fits into existing ISMS controls and quality processes.

Without clear procedures and training, the technical inclusion of the platform in your ISMS will not achieve consistent practice on the shop floor.

10. Practical sequencing checklist

A pragmatic sequence that works in most regulated, brownfield environments:

1. Decide that the platform is in scope based on business, regulatory, and data sensitivity criteria.
2. Define and document scope boundaries, assets, and interfaces in your ISMS documentation.
3. Perform or update the risk assessment, including supplier and integration risks.
4. Update the Statement of Applicability and control mappings, including shared responsibility with the vendor.
5. Integrate with change control, validation/qualification, and configuration management.
6. Verify implementation of key controls and evidence paths before broad rollout.
7. Update policies, procedures, and training; then monitor and refine based on incidents and audit feedback.

This approach keeps the inclusion of new digital platforms in your ISMS structured, evidence-based, and aligned with the realities of long-lived manufacturing systems.