octoplant Compliance: What a Change Management Tool Can Evidence

octoplant compliance is the question of what AMDT’s change management platform can prove to an auditor, and what it cannot. AMDT lists a long set of regulations its products support, from NIS2 and IEC 62443 to NERC CIP and FDA 21 CFR Part 11. No software makes a plant compliant. A tool like octoplant produces evidence and enforces some technical controls: backups that exist and are dated, versions that can be compared, changes that are attributed, alerts when a controller drifts. The procedures, the approvals, the risk assessment and the review remain the plant’s work.

This page sets out the frameworks AMDT maps to, separates what a tool can evidence from what it cannot, looks at the vendor’s own certifications, and ends with a checklist for an auditor or a buyer. The three pages beneath it go into the regulated cases in detail. For the company and product background, start at the AMDT hub.

The frameworks AMDT maps octoplant compliance to

AMDT’s OT compliance page groups the frameworks by region. Its pharma page adds EU GMP Annex 11 and GAMP 5, and its wider material cites GxP and Germany’s KRITIS rules. The table is the list as of October 2026, with our note on what each framework actually binds and where a backup and change tool touches it.

Region	Framework	Who it binds	Where a change management tool touches it
North America	FDA 21 CFR Part 11	FDA-regulated manufacturers keeping required records electronically	Audit trails, record protection, change control of computerized systems
North America	NERC CIP	Owners and operators of the bulk electric system	CIP-010 baselines and change monitoring, CIP-009 backup and recovery
North America	NIST CSF 2.0	Voluntary framework, often adopted by policy or contract	Asset management, protection, recovery functions
North America	CISA CPGs	Voluntary baseline goals for critical infrastructure	Asset inventory, backups, change logging
Europe	NIS2	Essential and important entities, including many manufacturers	Backup and disaster recovery, incident handling, asset management
Europe	IEC 62443	Asset owners, integrators and product suppliers, usually by contract	Configuration management, backup and restore, component inventory
Europe	EU GMP Annex 11	GMP manufacturers using computerized systems	Backups, audit trails, change and configuration management
Europe	ISO/IEC 27001	Organisations seeking ISMS certification	Asset inventory, backup, change management controls
Europe	EU Cyber Resilience Act	Manufacturers of products with digital elements	Mostly a supplier obligation; a plant feels it through procurement
Europe	KRITIS	German critical infrastructure operators	Recovery and evidence of state-of-the-art security measures
Asia-Pacific	Australia SOCI Act	Critical infrastructure asset owners	Risk management programmes covering cyber and recovery
Asia-Pacific	Singapore Cybersecurity Act	Owners of critical information infrastructure	Audits, risk assessments, incident reporting
Asia-Pacific	Japan METI guidance	Factory operators, voluntary	Asset knowledge, change control, recovery planning

Read the list as coverage of themes, not as certification. Every framework on it is about how an organisation manages risk. A tool appears in an audit as one source of evidence among many, next to the procedures it supports.

What an octoplant-type tool can and cannot evidence

The useful way to think about this is to ask what a sceptical auditor would accept from the tool’s output alone, and what they would ask a person for.

Evidence an auditor asks for	Can the tool produce it?	What still comes from the plant
A current backup exists for each in-scope device	Yes, from job history and the repository	Defining which devices are in scope
The backup can actually be restored	Partly: the tool holds the version	A recorded restore test on real or test hardware
What changed between two dates	Yes, through Smart Compare	Judging whether the change mattered
Who made a change, and when	Yes, for changes made through the tool’s workflow	Changes made outside it, on a laptop, are only detected, not attributed
The change was authorised before it happened	Partly, if approval workflows are configured and used	The approval procedure, the approver’s competence
Unauthorised changes are detected	Yes, through scheduled change detection	Someone reviewing the alert and recording the outcome
Firmware versions and known vulnerabilities per asset	Yes, with octovision	Risk acceptance, patch decisions, compensating controls
A risk assessment, zone model or security policy	No	Entirely the plant’s work
Training and competence records	No	HR and quality systems
The system itself is validated or assessed	No	Validation (GxP) or security assessment of the installation

The pattern in that table is the point. A change management tool is strong on what happened to the device. It is weak, by design, on whether the organisation responded correctly. Auditors increasingly test the second half: they pick an alert from last quarter and ask what was done about it.

A scenario, illustrative. A night-shift technician changes a timer preset on a filler to get past a nuisance stop. The next morning’s scheduled job uploads the controller, compares it with the approved version, flags the difference and emails the controls lead. That is good evidence that detection works. If the email sits unread for a month and the change is never assessed, the same evidence now shows a plant that detects unauthorised change and does nothing about it. The tool made the gap visible. It did not close it.

How the capabilities map to control families

Most frameworks, whatever their origin, ask for the same five things of an OT change process. The figure places octoplant’s features against those families, with examples of the clauses each one feeds.

Two observations from the mapping.

• Backup and change evidence are where the tool is strongest. These are also the controls auditors most often find missing in OT, because they depend on discipline at two in the morning. The version control and change management page explains the approved-version model that makes the evidence possible.
• Vulnerability management depends on octovision, which builds its asset list from octoplant data rather than network scanning. A plant without octovision has version data but not CVE matching in the same tool.

The vendor’s own certifications

A regulated buyer evaluates the supplier as well as the product. As of October 2026, AMDT’s Trust Center lists:

• ISO/IEC 27001:2022 for its information security management system, covering development, testing, distribution, support, consulting and training
• ISO 9001:2015 for its quality management system
• TISAX, the automotive industry’s information security assessment
• A vulnerability reporting channel

Release 105 was penetration tested by Outpost24, according to AMDT partner Novotek.

What we did not find: an IEC 62443-4-1 (secure development lifecycle) or 62443-4-2 (component) product certification for octoplant, a SOC 2 report, a public software bill of materials or a named product security incident response team. None of these is unusual for a software vendor of AMDT’s size, but a plant whose own policy requires 62443-certified components, or a supplier SBOM under the Cyber Resilience Act, should ask for current status in writing.

Limits and open questions

• The tool is part of the regulated system. In GxP plants octoplant itself is a computerized system that needs validation. In NERC CIP or NIS2 environments, a server holding every controller’s logic is a high-value target and must be protected and assessed like one.
• Coverage gaps become evidence gaps. If a device type is unsupported, or a machine is never reached by a job, the audit trail simply has nothing for it. AMDT’s device matrix sits behind the myAMDT login, so verify coverage per asset before relying on it.
• Out-of-band changes are detected, not attributed. An edit made directly from a laptop shows up at the next compare, without a reliable name attached unless the device itself records one.
• Edition features are not public. AMDT positions its Premium edition for regulated or large sites (pricing), but the per-tier feature split is not published. Confirm that approval workflows and audit features you need are in the edition you are quoted.
• Mapping tables are marketing until an auditor accepts them. Ask AMDT or its partner for a clause-level mapping and test it against your own auditor’s expectations.

How to evaluate it for compliance

A checklist for a quality lead, an OT security lead or an auditor reviewing a proposed or installed system:

1. Scope. Which in-scope devices are covered today, and which are not? Get the list, not a percentage.
2. Job health. What share of backup and compare jobs succeeded last month, and who is alerted on failure?
3. Approval workflow. Is approval enforced in the tool, or recorded elsewhere? Can an approver approve their own change?
4. Audit trail integrity. Can an administrator edit or delete audit records? How long are they retained?
5. Restore proof. When was a device last restored from the repository, and is there a record of it?
6. Alert review. Pick three change alerts from the last quarter. What was done about each?
7. Server security. Who has administrative access to the octoplant server, and how is the server itself backed up?
8. Validation or assessment. For GxP, is there a validation package and IQ/OQ record? For security frameworks, has the installation been assessed?
9. Supplier evidence. Current ISO 27001 certificate, vulnerability handling process, and any 62443 status.

If the answers are not known, a plant systems assessment is a reasonable first step: it establishes what is installed and what is actually protected before anyone argues about which framework applies.

Deeper

• octoplant and 21 CFR Part 11: audit trails, EU Annex 11, GxP change control, IQ/OQ and what validation still requires
• octoplant, NIS2 and IEC 62443: recovery, incident handling and configuration management evidence for European and 62443 programmes
• octoplant and NERC CIP: CIP-010 baselines, CIP-009 recovery plans, and where Industrial Defender competes

For the regulated industry view, see pharma and life sciences. Back to the AMDT hub, or across to version control and change management.