Smart Factory and Industrial IoT Security

A plant engineer receives an urgent message at 21:40. A packaging line is down, the equipment vendor needs remote access, and every minute of delay affects tomorrow's shipment. The vendor knows the machine. Operations knows the commercial cost. Security knows that a tunnel into the plant cannot simply remain open.

The difficult question is not whether to help the vendor connect. It is whether the organization can later explain which system was accessed, who requested it, who approved it, when permission expired, what data the system handled, and which evidence supported the decision.

I have seen this pattern repeatedly in privacy and compliance work. The factory is highly instrumented, yet the decision trail around the factory is surprisingly manual. Production technology may be sophisticated while the governance record is a mixture of inboxes, ticket comments, vendor portals, and personal memory.

That gap matters because operational technology is no longer isolated from data governance. Modern plant systems can involve maintenance identities, operator accounts, access logs, production records, camera feeds, connected sensors, and vendor support sessions. Some of that information can relate to workers or other identifiable people. Some systems may also support automated decision-making or connect to an incident process. Treating all of this as a generic cybersecurity inventory misses the operating context.

The central lesson is simple: smart-factory governance becomes defensible when the system record, the data record, the vendor decision, and the access history describe the same reality.

Place OT Evidence in the Current Regulatory Stack

ComplianceOne supports a Smart Factory OT/IIoT Data-Security Evidence Overlay. This is a platform-organized sector evidence layer, not a standalone government instrument or an industrial-security certification. Its profiles, vendor-access decisions and incident links connect plant context to the legal frameworks that apply to an organization's activities.

Worker accounts, camera images and maintenance identities bring the Personal Data Protection Law 91/2025/QH15 and Decree 356/2025/NĐ-CP into the review. Relevant administrative procedures are supported through Decision 778/QĐ-BCA. Industrial records also need assessment under the Data Law, Decree 165/2025 and Decision 20/2025 on important and core data. A production record is not automatically personal, important or core data; people assess the information and use involved.

The supported cybersecurity stack includes Law 116/2025/QH15 and Decrees 333/2026 on implementation, 331/2026 on information-system protection, 327/2026 on handling violating information and acts, and 330/2026 on cybersecurity and personal-data penalties. These instruments have different audiences and purposes. Decree 331's mandatory scope concerns systems serving state-agency operations and online services to citizens and businesses; other operators are encouraged to apply it. A private factory should not infer a mandatory system-level filing solely from owning connected equipment. Legacy Decree 85 material needs its preserved transitional context rather than presentation as the general current baseline.

Supplier activities may require additional review under Decree 332/2026 on cybersecurity-products and services business, or Decree 341/2026 on civil cryptography. These are role-specific questions, not automatic consequences of having a vendor or an encrypted connection.

Adjacent manufacturing frameworks stay tied to the activities they govern. Product quality and traceability, technical regulations, EPR, and chemical or hazardous-product evidence have their own supported overlays. An OT access approval does not demonstrate product conformity, environmental performance or chemical safety. An AI-enabled production system likewise needs its own AI Law, Decree 142, Circular 05 and Decision 33 applicability review; factory automation alone does not establish high-risk AI status.

Decree 169/2025/NĐ-CP, as amended by Decree 347/2026/NĐ-CP, concerns data products and data services, while Decree 314/2026/NĐ-CP governs the operation of data platforms. These instruments do not automatically apply merely because a factory operates industrial databases or connected equipment; their actual regulated activity must be assessed separately.

Decree 363/2026 on data-sector penalties remains upcoming until 11 November 2026. This layered review preserves scope without claiming that ComplianceOne discovers devices, enforces network access, classifies systems autonomously or certifies a plant.

Smart Factory Governance Does Not Stop at Cybersecurity

A connected production system can affect more than privacy and cybersecurity.

Where manufacturing systems create, modify or retain evidence used for product classification, production quality, batch or lot traceability, conformity, labelling, recalls, environmental obligations or controlled-chemical handling, the applicable manufacturing framework must be reviewed separately.

ComplianceOne's supported Vietnam manufacturing stack includes product and goods quality, product traceability, technical regulations, EPR, chemical and hazardous-product obligations, as well as the Smart Factory OT/IIoT evidence overlay.

This does not mean that every PLC, camera or IIoT gateway falls under every manufacturing rule. The regulated product, production activity and organizational role determine applicability.

The governance advantage is that one production-system record can point to the different evidence processes affected by that system without pretending that one OT control satisfies every legal requirement.

The Factory Has Many Truths

Ask five teams to describe one industrial system and you may receive five correct but incomplete answers.

The plant engineer describes its role in production. IT describes its network address and support arrangement. Procurement describes the vendor contract. Privacy describes the categories of information it may handle. Security describes its exposure and controls. Compliance describes the applicable obligations and evidence.

A maintenance gateway might exist in a plant list but not in the enterprise data inventory. A vendor may be approved in procurement while the specific access grant is undocumented. A system may process operator identifiers, but the worker-data question may never reach the privacy team. An incident may be logged without a durable link back to the affected system profile.

This fragmentation produces familiar symptoms:

• System names differ across departments, making evidence hard to reconcile.
• Vendor access is approved through chat or email, with no structured expiry.
• The organization knows a system exists but cannot show what data-governance questions were answered about it.
• An access decision records the requester but not an independent approver.
• A review shows the current state but not the state that existed when the decision was taken.
• Incident evidence and system context have to be assembled manually under pressure.

These problems do not prove that the factory is insecure. They show that the organization may struggle to demonstrate how it governed the factory. Compliance evidence should faithfully record the governance actions actually taken, not pretend to measure machine safety or network resilience.

Why Another Asset Spreadsheet Is Not the Answer

The obvious response is to create a dedicated operational technology inventory. That can help locally, but it also creates another source of truth.

If the same system appears once in an enterprise systems inventory and again in a plant spreadsheet, ownership begins to drift. One record says the vendor changed. Another says the system handles worker identifiers. A third contains the current support arrangement. Reviewers spend their time deciding which record to trust.

A stronger design starts from the live system already held in the organization's data inventory. The operational technology profile extends that system. It does not create a competing asset identity.

The plant view and the data-governance view now point to the same machine without duplicating its name, owner, and inventory relationship. It also sets an honest boundary. ComplianceOne does not scan a plant network, detect controllers, ingest telemetry, or create an inventory from machine traffic. The organization establishes the system first, then adds the operational technology profile.

I prefer that honesty to an inflated claim about visibility. A manually governed record that clearly states its provenance is more useful than a supposedly complete inventory whose discovery limits nobody can explain.

Remote Access Is a Decision, Not Just a Connection

Remote maintenance creates one of the clearest tests of industrial governance.

The technical connection may last thirty minutes. The accountability question lasts much longer. Who needed access? Which vendor received it? Which system was in scope? Who approved the request? When did the grant expire? Was it revoked? Was an unapproved request ever mistaken for active permission?

Those questions require more than a VPN log. A connection log may show that traffic occurred. It does not necessarily show the business justification, the accountable requester, or the approving person.

A structured grant record should therefore capture the decision around access, not merely the technical event. In ComplianceOne, the grant references a vendor and an operational system, requires an expiry in the future, and separates the requester from the approver. An expired or revoked grant cannot later be approved.

The status is derived from the approval and the clock when the register is read. A request that nobody approved remains pending approval. It is not presented as active simply because a record exists.

Documentation and authorization must remain separate.

A Practical Governance Model for Industrial Systems

The most useful way to approach smart-factory governance is to organize it around five linked records: the system, its operational profile, the vendor, the access decision, and the resulting evidence history.

Each record answers a different question:

• The system record answers what the organization operates and who owns it.
• The operational profile answers why the system matters in the plant and which governance questions attach to it.
• The vendor record answers which third party is involved.
• The access grant answers why access was requested, who approved it, and when it ends.
• The history answers what was known and decided at a particular time.

Keeping these records connected avoids two extremes. The first is a security inventory with no business meaning. The second is a compliance narrative with no connection to the actual system.

1. Begin With a Named, Live System

The first control is identity. Every operational technology profile should extend a live system in the data inventory, with one profile per system.

This prevents teams from creating a vague record called "Factory network" and attaching every concern to it. The organization instead works with specific systems that can be owned, reviewed, and connected to evidence.

The record should use language the operating team recognizes. If engineering calls a system the line-three vision controller, the governance team should not silently rename it a manufacturing analytics platform. Precision reduces reconciliation work later.

At this stage, the organization should establish:

• The system owner and operating context.
• The plant or production process the system supports.
• Whether the system handles data relating to workers or other people.
• Whether it connects to an AI governance question.
• Whether an incident record needs to reference it.
• Which vendor relationships support it.

This foundation allows technical, privacy, vendor, and compliance reviews to refer to the same object.

2. Treat Worker Data as a Design Question

Industrial systems are often discussed as though they process only machine data. That assumption is increasingly fragile.

Badge events can identify who entered a zone. Operator accounts can tie actions to individuals. Cameras can capture workers. Maintenance tickets can contain names and shift details. Performance dashboards can make individual activity visible. Access logs can associate an engineer with a sensitive system.

The right governance question is not whether the factory is a human-resources system. It is whether a particular industrial system handles information that relates to a person, and what follows if it does.

A simple worker-data question in the operational profile creates a routing point. If the answer is yes, the privacy team can examine purpose, access, retention, transparency, and other applicable controls through the organization's established process. If the answer is no, the organization still has a dated statement that can be reviewed when the system changes.

This avoids waiting for someone to label a project "personal data." The more reliable trigger is the system and its actual information flows.

3. Give Every External Access Grant a Boundary

External access should be purpose-bound and time-bound. A grant without an expiry becomes an informal standing entitlement, even when everyone originally intended a one-off intervention.

Requiring an expiry in the future changes the conversation at creation time. The requester must decide how long the vendor genuinely needs. The approver can evaluate a defined period rather than an indefinite promise.

The evidence record should make the following visible:

• The vendor receiving access.
• The specific operational system in scope.
• The reason access is needed.
• The person requesting it.
• The person approving it.
• The approval time and expiry.
• Any later revocation.
• Supporting material that explains the decision.

The platform blocks the obvious self-approval by preventing the requester from acting as approver. That is a meaningful control, but it should not be exaggerated. Organizations still need to assign roles carefully. A permission model can make separation possible, while the operating model determines whether the right people actually hold those permissions.

4. Derive Status From Evidence and Time

Stored status labels become stale. A row marked active can remain active long after midnight on its expiry date. A revoked grant can be displayed incorrectly if a later manual edit overwrites its state.

Deriving status from the approval record, revocation record, expiry, and current time reduces that ambiguity. The grant reads as pending approval, active, expired, or revoked according to the evidence available when it is viewed.

This is especially valuable during review. The compliance lead does not need to trust that someone remembered to change a dropdown. The visible state follows the underlying facts.

The design also preserves an important negative fact: nobody approved this request. Pending approval is not an incomplete version of active access. It is a distinct governance state that deserves attention.

5. Preserve the Difference Between Event Time and Record Time

Plant evidence is frequently entered after the event. A technician resolves an outage first, then records what happened. A vendor completes maintenance, then the supporting report arrives. An incident is identified on one day and formally logged on another.

A credible evidence model distinguishes when something happened from when somebody recorded it. Collapsing the two timestamps produces false precision and can distort an investigation.

This principle also applies beyond access. Manufacturing trace records benefit from preserving the original event and adding a reasoned correction rather than editing history. The same principle becomes especially important where production systems contribute evidence used for batch, lot or product traceability. A corrected trace event should not silently erase the original production record. ComplianceOne can govern the evidence history around those changes while the MES, ERP, WMS or specialist traceability system remains the operational system of record. 

Product traceability is also moving further into the regulatory foreground. ComplianceOne already supports the upcoming Decree 372/2026/NĐ-CP on product and goods identification, authentication and traceability, effective 1 January 2027. Organizations should treat it as a separate applicability and readiness workstream rather than describing it as already effective. 

ComplianceOne's traceability record is append-only: a correction is a new event, the earlier event remains readable, and the correction must explain why the previous entry was wrong.

That is not a claim of cryptographic immutability. It is a clear operational rule against overwriting or deleting the historical event. The distinction matters because evidence should be described at the strength it actually has.

The Night-Shift Vendor Intervention

Return to the packaging-line outage. The maintenance lead identifies the affected system and selects the equipment vendor already held in the vendor register. The request states that the vendor needs diagnostic access to investigate a controller fault, names the plant system, and sets an expiry aligned with the maintenance window.

An authorized colleague reviews the request. That reviewer can see the system context and the purpose of access. Because the requester cannot approve their own grant, the record captures a second accountable decision. Once approved, the grant reads as active until it is revoked or expires.

If the repair finishes early, the team records revocation. If the window passes, the status becomes expired according to the clock. If nobody approves the request, it remains pending approval and cannot be mistaken for sanctioned access.

The governance evidence now answers a coherent set of questions. It does not prove what packets crossed the network or what commands the vendor issued. Those facts belong in the relevant technical systems. It proves who made the access decision, which system and vendor it concerned, the purpose stated at the time, and the period authorized.

That is the right division of responsibility. Production and security tools keep doing their jobs. The compliance record connects the decision and its supporting evidence.

A Worker-Data Review for a Vision System

Consider a quality-inspection camera introduced on a production line. The primary purpose is to identify defects in packaged goods, but the camera's field of view may also capture operators. User accounts and review logs may associate actions with named employees.

The plant owner first ensures the vision system exists in the enterprise data inventory. The operational profile then records its manufacturing context and answers the worker-data question. A positive answer does not automatically declare the processing lawful or unlawful. It creates a reliable point for privacy review.

The privacy lead can then work through the organization's applicable questions: what information is captured, for what purpose, who can see it, how long it remains available, what notices apply, and how changes are reviewed. Security can address access and protection. Operations can explain why the system exists and how it behaves in practice.

All three disciplines refer to the same system. That is the operational gain. The organization does not need to reconstruct the relationship between "camera project," "inspection appliance," and "line quality platform" during an audit because the profile extends one named record.

When the field of view, software, vendor, or purpose changes, the existing profile creates a natural review point. Governance stays attached to the system lifecycle instead of becoming a one-time project document.

An Incident Review That Starts With Context

Imagine that a vendor account is used outside the expected support window. The security team investigates the technical evidence and opens an incident record. The compliance team needs more than an alert timestamp. It needs to understand the affected system, the vendor relationship, the access decision, and the data context.

Because the operational profile and grant point back to established records, the review can begin with context rather than identity matching. The team can compare the observed activity with the authorized period, examine who requested and approved access, and locate the material that supported the grant.

The result may show a control failure, a technical error, or permitted activity that was poorly communicated. The governance system should not prejudge the conclusion. Its role is to preserve the inputs and ownership needed for a reasoned decision, reducing the facts that must be rediscovered under pressure.

What Leadership Should Ask Every Quarter

Executives do not need a tour of every controller. They need assurance that industrial access and data questions have accountable owners and reviewable evidence.

A quarterly conversation can start with five questions:

1. Which operational systems still lack a completed governance profile?
2. Which profiles indicate worker data and need current privacy review?
3. Which vendor access requests remain pending approval?
4. Which grants expired or were revoked, and were any related incidents raised?
5. Can the team reconstruct one recent access decision without searching personal inboxes?

These questions move leadership away from a false binary of secure or insecure. They test whether the organization has an operating discipline capable of finding ambiguity and assigning it.

Metrics should remain careful. Counting profiles or grants can show workload and coverage, but it does not prove security effectiveness. A factory with more recorded incidents is not automatically less secure; it may have better detection and reporting. A factory with no pending requests may have excellent governance or may be bypassing the process.

Numbers become useful when they lead to evidence-based questions rather than decorative assurance.

The Shift From Plant Documentation to Plant Accountability

Smart-factory compliance is often treated as a documentation exercise that follows engineering. A system goes live, and governance teams later ask for a diagram, a vendor list, and a policy exception.

The better model is to make accountability part of the operating record. The system is named once. Its industrial context extends the data inventory. Worker-data and AI questions are visible. External access is tied to a vendor, purpose, approver, and expiry. Incident evidence can point back to the same context.

The value of ComplianceOne is not deeper technical control of the plant. It is regulatory coherence around the plant.

MES, SCADA, ERP, WMS, IIoT, identity, security and vendor-support systems continue to perform their operational functions. ComplianceOne connects the evidence those systems produce to applicable regulatory obligations, named owners, approvals, exceptions, incidents, attestations and audit-ready records.

That gives privacy, security, operations, quality, legal and compliance teams a shared evidence chain without forcing them into one operational system.

I do not think governance platforms should pretend to run the factory. The most credible role is narrower and more valuable: preserve what the organization knew, who decided, what boundary applied, and which evidence supported the decision.

That mindset changes compliance from a periodic reconstruction into a byproduct of responsible operations.

Industrial IoT governance becomes manageable when teams stop building separate truths for operations, privacy, security, vendors, and compliance. The goal is not to force every discipline into one tool. It is to give their decisions a shared system identity and a reviewable evidence chain.

To see how connected system profiles, vendor governance, approval records, and audit-ready evidence can work in daily compliance operations, explore  AesirX ComplianceOne.

Ronni K. Gothard Christiansen
Technical Privacy Engineer and CEO, AesirX.io

Laws and instruments referenced

Personal Data Protection Law 91/2025/QH15 and Decree 356/2025/NĐ-CP cover personal-data issues that may arise from worker accounts, camera images, maintenance identities and other identifiable information in industrial systems.

Data Law 60/2024/QH15, Decree 165/2025/NĐ-CP and Decision 20/2025/QĐ-TTg provide the wider data-governance framework, including assessment of important and core data.

Cybersecurity Law 116/2025/QH15 and Decrees 333/2026, 331/2026, 327/2026 and 330/2026 form the current cybersecurity stack referenced for implementation, information-system protection, violating-information handling and penalties.

Decree 332/2026/NĐ-CP and Decree 341/2026/NĐ-CP may require separate assessment where suppliers provide regulated cybersecurity products or services, or activities involve civil cryptography.

AI Law 134/2025/QH15, Decree 142/2026/NĐ-CP, Circular 05 and Decision 33 are relevant where AI-enabled production systems require a separate AI applicability assessment.

Decree 169/2025/NĐ-CP, as amended by Decree 347/2026/NĐ-CP, concerns data products and data services, while Decree 314/2026/NĐ-CP governs the operation of data platforms. These instruments do not automatically apply merely because a factory operates industrial databases or connected equipment; their actual regulated activity must be assessed separately.

Decree 363/2026/NĐ-CP covers data-sector penalties and takes effect on 11 November 2026.

Disclaimer

This article provides general operational and compliance information from a platform vendor and does not constitute legal, cybersecurity, engineering or other professional advice. Regulatory applicability depends on the organization, system, activity, data processing, technology, vendor role and jurisdiction. ComplianceOne supports governance and evidence management and does not certify industrial systems, operate machinery, perform asset discovery or replace OT security controls. Organizations should confirm applicable obligations with qualified legal, compliance, cybersecurity and technical professionals.

Frequently Asked Questions About Smart Factory and Industrial IoT Security

Smart Factory Governance in Practice

See how ComplianceOne connects factory systems, vendor access, worker data, approvals and
regulatory evidence without replacing operational technology or security systems.