Running a data governance audit: from policy to shop-floor proof, MBA Training, MBA Training
4/4+150 XP
Running a data governance audit: from policy to shop-floor proof
# Running a data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète → audit: from policy to shop-floor proof
A plant manager in Ohio pulls up the MES (Manufacturing Execution System) dashboard and finds three years of operator login records still sitting in active storage, four years past the retention limit the company's own policy set. Nobody deleted them because nobody was assigned to check. That single gap, found during a routine audit, is exactly the kind of thing that turns a clean-looking governance policy into a real liability.
Data governanceData governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète → policies read well in a boardroom deck. The real test is whether they survive contact with a shop floor running three shifts, three PLC (Programmable Logic Controller) vendors, and a contractor list that changes every quarter. An audit is how you find out before a regulator, a customer, or an attacker does.
Why manufacturing governance audits are different
Manufacturing data lives in more places than office data. You're auditing:
MES records (production counts, quality holds, operator IDs, timestamps)
SCADA/PLC (Supervisory Control and Data Acquisition / Programmable Logic Controller) logs from machine controllers
ERP (Enterprise Resource Planning) systems holding supplier and customer data
IIoT (Industrial Internet of Things) sensor streams from predictive maintenance systems
Access control systems for badge and network entry
Each system has different owners, different retention rules, and often different vendors, some of them decades-old equipment never designed with data privacy in mind. A 2015 PLC controlling a stamping press was not built thinking about GDPR (General Data Protection Regulation, the EU's 2018 data privacy law).
The regulatory backdrop, briefly
You don't need to be a lawyer, but you need to know what an audit is checking against:
GDPR (EU, in force since 2018): governs personal data of EU employees and customers, including operator names tied to machine logs. Requires data minimization and defined retention limits.
CCPA/CPRA (California Consumer Privacy Act / Privacy Rights Act): similar personal-data protections for California-linked data subjects, relevant if a US manufacturer sells to California customers or employs California residents.
NIST Cybersecurity Framework (US, voluntary but widely adopted, especially by defense-linked manufacturers): nist.gov/cyberframework sets practical control categories: Identify, Protect, Detect, Respond, Recover.
IEC 62443: the main international standard specifically for industrial control system (ICS) security, the one auditors reference when checking PLC and SCADA network segmentationsegmentationDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.Voir la définition complète →.
CMMC (Cybersecurity Maturity Model Certification): required for US Department of Defense suppliers, increasingly a de facto benchmark even for non-defense manufacturers.
None of these tell you exactly how to run your plant. They set the bar. The audit is where you measure your plant against that bar.
The audit checklist: three concrete tests
Test 1: Sample MES records for retention compliance
Pick a random sample of MES records (say, 50 batches from the last two years). For each, check:
Does a documented retention rule exist for this record type (e.g., "quality records: 7 years," "operator login logs: 90 days")?
Is the actual data age within that limit?
If deletion should have happened, is there a deletion log proving it did?
Worked example: Policy says badge-access logs are kept 180 days. You sample 50 records. 42 fall within 180 days. 8 are older, one is 14 months old. That's an 84% compliance rate on this sample, well below an acceptable threshold (most internal audit standards look for 95%+ before calling a control "effective"). The finding: retention deletion is not automated, it depends on someone remembering.
Fix pattern: automate deletion via a scheduled job rather than manual review, and log every deletion event for evidence.
Test 2: Verify access logs against role definitions
This is where governance policy meets reality. Pull the role-based access control (RBAC) matrix, the document defining who should access what, and compare it against actual system logs.
Concretely:
1. Export the last 30 days of login events from the MES and SCADA historian.
2. Cross-reference each user against their assigned role (operator, quality engineer, maintenance contractor, plant IT).
3. Flag any access outside the defined role, e.g., a contractor account with write access to recipe parameters when their contract only authorized read-only diagnostics.
# Simplified access-audit logic (pseudocode)
for user in access_log:
role = role_registry.get(user.id)
if user.action not in role.permitted_actions:
flag_finding(user, role, user.action, timestamp)
This kind of query is trivial once logs are centralized, but many plants still have PLC-level access that never reaches a central log at all, which is itself a finding worth writing up.
Test 3: Run an incident-response drill for a simulated PLC breach
Tabletop exercise: assume an attacker has gained remote access to a PLC controlling a critical process (a furnace, a chemical mixer, a robotic weld cell). Time how long it takes the team to:
Detect the anomaly (unusual command pattern, unexpected parameter change)
Isolate the affected network segment
Notify the required parties (internal security, and if personal or safety data is implicated, regulators within GDPR's 72-hour breach notification window)
Restore from a known-good backup
Real-world reference point: the 2021 Colonial PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → ransomware incident (US) showed how operational technology (OT) and information technology (IT) can be tightly coupled in ways that turn an IT breach into a production shutdown. Manufacturing plants with poor IT/OT network segmentationsegmentationDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.Voir la définition complète → face the same exposure.
🎬 [VIDEO: "Industrial Control Systems Security Basics" - youtube.com/@CISAgov - CISA's overview of ICS/SCADA security fundamentals for critical infrastructure and manufacturing environments]
Vérification des acquis
1. The Ohio plant example (operator login records kept years past the retention limit) illustrates what kind of governance failure?
2. Why do manufacturing data governance audits tend to be more complex than typical office IT audits?
3. A company discovers that a 2015-era PLC controlling a stamping press logs operator IDs indefinitely with no way to configure automatic deletion. What is the most appropriate governance response?
CHOIX MULTIPLES
4. Select ALL correct answers about why an audit is described as necessary to catch governance gaps 'before a regulator, a customer, or an attacker does.'
Sélectionnez toutes les réponses correctes.
CHOIX MULTIPLES
5. Select ALL correct answers about the challenges that make shop-floor systems distinct audit targets compared to standard office IT systems
Sélectionnez toutes les réponses correctes.
Building the audit report that actually gets used
An audit that produces a 40-page PDF nobody reads is worse than no audit. Structure findings so plant managers and compliance officers can act:
| Badge logs retained 14 months past policy | Medium | Sample of 50 records, 8 non-compliant | Plant IT | Q2 |
| Contractor has write access beyond role | High | Access log cross-reference | Security lead | Immediate |
| Breach drill: 47 min to isolate segment (target: 15 min) | High | Drill timing log | OT security | Q1 |
Each row needs a named owner and a date. Governance audits fail in practice not because nobody finds problems, but because findings sit in a report with no accountable owner.
Common failure patterns worth naming
Shadow IT on the shop floor: engineers connecting a laptop directly to a PLC for troubleshooting, bypassing logged access entirely.
Vendor blind spots: OEM (Original Equipment Manufacturer) service contracts that grant remote access for maintenance, rarely reviewed after initial signing.
Retention policy that exists only on paper: written in the governance manual, never implemented as an automated control.
Access reviews done annually instead of continuously: a contractor's access outlives their contract by months.
An audit is the proof layer for governance policy: sample real MES and access records rather than trusting the policy document alone.
Retention compliance should be measured with a concrete sample and a pass threshold (aim for 95%+); anything lower signals a manual, unreliable process.
Access audits require comparing logs against a documented RBAC matrix, and PLC-level access that never reaches central logging is itself a governance gap.
Incident-response drills need a timed benchmark (detection, isolation, notification, recovery) since GDPR and similar regimes impose fixed breach-notification windows.
Every audit finding needs a named owner and a deadline; unresolved findings are the most common reason audits fail to change plant-floor behavior.