A vendor account team pitches your plant manager a 'closed-loop optimization' add-on: KaizenFlow would push recommended setpoints directly to PLCs 'within safe limits.' The plant manager asks you to sign off.
Q1 Your call as platform owner?
A
Yes, if the writes are rate-limited and logged. Logging a write doesn't unmake it. The review question is whether the platform can ever actuate equipment — rate limits change how often, not whether.
B
Yes, but only on a pilot line to contain the risk. A pilot normalizes the coupling. Once one line accepts writes, the boundary is gone from the architecture — and from your security review answers.
C
No. Any write path to controllers moves KaizenFlow into the control path — the read-only boundary is why its worst failure is a stale dashboard, not a stopped line. 'Within safe limits' still means a bad deploy or compromised account can actuate equipment. The one-way flow is the architectural commitment everything else rests on.
Covered in Module 01
To cut latency, the network team proposes letting the cloud platform poll the plant's OPC-UA servers directly — opening an inbound firewall path from IT to OT and retiring the edge collector.
Q2 What do you keep, and why?
A
Retire the collector and move the whole platform into the OT zone instead. That collapses the IT/OT boundary from the other side — analytics, dashboards, and all their users land inside the zone the firewall exists to protect.
B
The edge collector in the DMZ and the single documented egress conduit — no inbound path to OT, ever. Zone-and-conduit means one auditable way out and no way in. An inbound path from IT to OT turns every platform compromise into a plant-network problem.
C
Open the inbound path but restrict it to the OPC-UA port. A scoped hole is still a hole into the control network. The pattern's strength is that OT accepts no inbound at all — one conduit, outbound only.
Covered in Module 01
Your cloud region goes down at 09:40. The COO calls: 'Are my lines stopping?' The edge collectors are still powered and the plant network is untouched.
Q3 What do you tell the COO?
A
Production is unaffected — KaizenFlow only reads a copy of plant data. Dashboards go stale, collectors buffer locally, and history backfills when the region returns. This is the designed failure mode. Nothing in the control path depends on the platform, and the local buffer means you lose freshness, not the record.
B
Production is fine, but the outage window's data is lost. The collector's local buffer exists for exactly this hour. Uplink returns, buffer drains, the record is whole.
C
Lines may stop — get maintenance to switch the PLCs to local mode as a precaution. There's nothing to switch. The PLCs never depended on the platform; 'precautions' like this create the downtime the architecture makes impossible.
Covered in Module 01
A quarterly access review turns up an integration contractor whose engagement ended in March — account still active with connector-config rights, last login two weeks ago.
Q4 Beyond disabling the account, what's the systemic fix?
A
Send admins a monthly reminder to check for stale accounts by hand. A reminder is the process that already failed. Manual sweeps miss what automation catches on the day it happens.
B
Require stronger passwords on contractor accounts. The problem isn't how strong the credential is — it's that the account existed at all after the work ended. Two weeks of live access rode on that gap.
C
Wire deprovisioning to the IdP — SCIM/group sync so ending the engagement kills access automatically — keep the periodic review as the drift-catcher, and rotate the connector credentials the account could read. The account is a symptom. Lifecycle automation is the fix, the review is the safety net, and any secret that account could see gets rotated on principle.
Covered in Module 02
An engineer spots what they're sure is a wrong verified-savings entry — a changeover fix double-counted — and asks for ledger-edit rights 'for ten minutes' to correct it.
Q5 How does the correction happen?
A
Grant the ten-minute exception and revoke it after — the fix is obviously right. Temporary super-rights are how separation of duties dies. The audit question isn't whether this edit was right; it's whether engineering can ever rewrite savings.
B
Through finance. Engineering flags the entry with evidence; finance makes the correction under its own role, and the change lands in the append-only audit trail. Even a right correction made by the wrong role poisons the ledger — the people who produce the data never adjust the verified number.
C
Have an admin make the edit quietly, since admin already manages the platform. Admin is deliberately separated from silent ledger edits for exactly this reason. A 'quiet' fix by admin is the least defensible version of the change.
Covered in Module 02
During the annual audit, the auditor asks: 'How do I know an admin didn't quietly adjust a Q2 ledger entry after finance verified it?'
Q6 What do you show?
A
The admin team's written attestation that no changes were made. Attestation is exactly what evidence replaces. If the control were 'we promise,' the audit wouldn't need a log at all.
B
The ledger database's last-modified timestamps. Timestamps stored in the same database an admin controls prove nothing — the tamper you're ruling out could rewrite them too.
C
The append-only audit log, exported to the SIEM outside the platform — every ledger change, with actor and timestamp, in a store no platform admin can edit. Immutability plus independent retention is the whole answer. The log doesn't ask the auditor to trust the platform — it survives the platform.
Covered in Module 03
Two days before go-live, an integrator wants to ship a new connector with its service credentials in the config file — 'we'll move them to the secrets manager after launch.'
Q7 You say —
A
Fine if the config file's permissions are locked to the service account. File permissions don't survive backups, images, or repo commits — and rotation still isn't scheduled. The manager exists because file ACLs keep failing this exact test.
B
Fine for launch week, with a ticket to migrate afterward. The ticket doesn't unspread the secret. Config files get committed, backed up, and shared — day one in plaintext can mean years of exposure.
C
No. Credentials go into the secrets manager before the connector ships — plaintext-in-config is a standing review failure, and 'after launch' cleanups don't happen. Secrets handling isn't a polish step. A credential that ships in a file gets copied, backed up, and diffed into places you'll never fully claw back.
Covered in Module 03
A customer's security team sends a SOC 2-based questionnaire ahead of a deal. You have a week to assemble the response for your KaizenFlow deployment.
Q8 What's the spine of your answer?
A
A signed copy of the corporate security policy. Policy says what should happen; the questionnaire asks what does. Controls mapped to evidence is the difference between an answer and a promise.
B
The four control families mapped to evidence: encryption (TLS, at rest, BYOK), access (SSO + MFA, least-privilege RBAC, separation of duties), logging (append-only trail, SIEM export, privilege alerts), boundary (read-only OT, documented egress). That's the review checklist doing its job: every question they ask lands in one of the four families, and each control points at evidence, not intention.
C
A network diagram and the vendor's own SOC 2 report. The vendor's report covers the vendor. The reviewer is asking about your deployment — your roles, your keys, your logs, your boundary.
Covered in Module 03
An auditor picks one line from the ledger — '$18,400, reduced changeover loss, Line 2, March' — and asks you to show where it came from.
Q9 What does a passing answer look like?
A
Re-run this quarter's model on March's data and show the result matches. Today's model may not be March's. The ledger is defended by the methodology version applied at the time — not by whatever the current version happens to say.
B
Show the March dashboard screenshot where the figure appeared. A screenshot shows the number existed, not where it came from. The auditor is asking for inputs and calculation, and only lineage carries those.
C
A walk backward through the lineage: the raw event IDs, the reason codes with any human edits, the loss calculation, and the methodology version in force in March — ending at finance's verification. That chain is what lineage is for. Every hop was captured at write time, so the answer is a walk, not a reconstruction.
Covered in Module 04
Legal forwards a GDPR erasure request from a former operator. Their ID appears in reason-code annotations and shift logs. An admin offers to 'just delete everything with that ID tonight.'
Q10 What has to happen instead?
A
Refuse — manufacturing data is exempt from GDPR. Annotations and shift logs tied to a person are personal data. Assuming exemption is the same gamble as assuming residency doesn't apply.
B
Let the admin delete it tonight — erasure requests override everything. Erasure gets executed against ownership and retention duties, not around them. Blind deletion can destroy ledger evidence you're required to keep.
C
The documented owner of each affected data class decides — ownership set before go-live determines who signs off on deletion, weighed against what the retained ledger evidence requires. That's what per-class ownership is for. Deletion isn't an admin's keystroke; it's the owner's sign-off, balanced against evidence-retention duties.
Covered in Module 04
Monday 06:00: the weekend looks flawless — Line 4 shows 98% OEE with zero downtime. The weekend crew swears the capper was down twice. You find the connector died Friday 22:00 and the tiles froze on the last good data.
Q11 What's the fix that outlasts this incident?
A
Retrain the weekend crew to log downtime more carefully. The crew wasn't the failure — the pipe was. No amount of logging discipline reaches a platform whose connector is dead.
B
Alert on ingestion freshness and connector status, and treat 'data stopped flowing' as a first-class incident — a silent dead connector reads as a perfect weekend. Stale data doesn't look broken; it looks calm. Freshness monitoring turns a quiet gap into a page instead of a Monday surprise.
C
Accept the 98% — the system of record says the weekend was clean. The record stopped Friday 22:00. Trusting frozen tiles over the crew's account is how missed downtime becomes missed savings.
Covered in Module 05
Your semiannual access review finds two things: a supervisor who transferred plants in April still holds their old plant's role, and a contractor account from a finished project retains admin rights.
Q12 What does the cleanup look like?
A
Note both for the annual audit — neither account has actually done anything wrong. Standing unneeded privilege is the risk, not just misuse. A leftover admin credential is exactly what the 2 a.m. incident starts from.
B
Fix both in the IdP — move the supervisor's group membership, disable the contractor — and treat the pair as a signal that the mover and leaver steps aren't fully wired to the IdP. Role creep and orphaned accounts are joiner-mover-leaver failures. Fix the instances where access lives — the IdP — then fix the process that let them survive.
C
Edit both users' roles directly in KaizenFlow — it's faster than touching the IdP. Hand-edits fork the truth: the IdP re-asserts the wrong state on the next sync, or the drift slides silently past the next review. Access changes happen where access lives.
Covered in Module 05