An OT Service Case Study Without Exposing Sensitive Systems
An OT service case study can prove capability without publishing network diagrams, vulnerabilities, remote-access paths or identifiable incident detail. The public page should explain the operating problem, approved scope, method, constraints and outcome at the level a buyer needs.
Security review should happen before writing, not after the page is designed.
What can an OT case study publish safely?
Publish the industry and asset class at an approved level, business or operational problem, supplier role, assessment or delivery method, project period, non-sensitive deliverables, measured process outcome and explicit exclusions. Keep addresses, topology, ports, accounts, unpatched weaknesses, incident indicators and security controls confidential unless the owner approves release.
| Useful public evidence | Usually restricted |
|---|---|
| Asset class and broad operating context | Site and system identity |
| Supplier scope and project stage | Detailed architecture and data flows |
| Standards or method applied | Vulnerability and exploit detail |
| Number or type of workshops | Names, accounts and access routes |
| Approved process improvement | Logs, indicators and incident timeline |
| General constraint and learning | Control weakness and residual risk register |
OT case study publication boundary separating useful public evidence from restricted system and security details.
Classify information before drafting
Bring the asset owner, security lead, project manager and marketing owner together. Mark source material as public, tender-only, internal or restricted. Record the reason and approving owner.
Germany's BSI provides industrial control system security guidance. Its existence does not make a client's implementation public. Project confidentiality and security controls still apply.
Describe the operational problem
Use a business or engineering description rather than exposing the weakness. Examples include unclear asset ownership, inconsistent remote-support approval, incomplete recovery documentation or limited visibility of configuration changes.
Avoid language that tells an attacker which product, location or control failed.
State the supplier's exact role
Was the work discovery, asset inventory, architecture review, risk assessment, segmentation design, access-process design, monitoring setup, incident support, recovery planning or training?
State whether the supplier advised, implemented, tested or independently reviewed. Do not use "secured the plant" when the appointment covered one part.
Explain the method without revealing the target
A safe method section can show phases, responsibilities and deliverables:
- confirm scope and rules of engagement
- gather approved records and interviews
- validate assets or processes using agreed methods
- assess gaps and operational consequences
- prioritise actions with owners
- verify selected changes
- hand over controlled records
Do not publish scanning methods, test payloads, credentials or unclosed findings.
Choose outcomes that do not expose controls
Useful outcomes may include:
- asset ownership assigned
- access approvals consolidated
- recovery responsibilities tested
- unsupported components placed on a replacement plan
- monitoring coverage defined
- incident contacts and escalation agreed
- actions prioritised by operational consequence
Quantify only with approved numbers and boundaries. "All critical assets" should be supported by a defined inventory scope.
Use diagrams with abstract boundaries
Show the relationship between governance, operations, engineering and supplier support rather than actual zones or connections. Label diagrams as illustrative when they are not the client's architecture.
Do not use a blurred screenshot if the underlying layout can still be inferred. Rebuild a safe diagram from approved concepts.
Create a claim and disclosure review
For each sentence, record the source, classification, technical reviewer, client permission and review date. Red-team the draft by asking what a reader could infer when it is combined with public job adverts, product pages and location data.
Build a safe evidence hierarchy
Start with the service process and deliverables. Add anonymised measures only when they cannot identify the site or reveal coverage. Use a client quote only after checking that it does not confirm a security weakness or incident.
Offer deeper evidence through a controlled buyer conversation. A procurement team may review a redacted report structure, assessor qualifications or a reference under NDA without receiving system data.
Give the page a withdrawal trigger
An OT case study may become riskier after an acquisition, public incident, technology disclosure or change in site status. Record events that require review and a contact who can remove the page promptly.
Keep an archived approved version and decision log. Deleting the source files makes it harder to understand what was public if a question appears later.
Avoid invented anonymity
Changing the client name to "a European manufacturer" may not be enough when the image, date, equipment and location identify the plant. Test the complete story against public information and reduce detail until the owner accepts the residual inference risk.
Safe case-study checklist
- Asset owner and security reviewer involved
- Source material classified before writing
- Client and site identity handled as approved
- Supplier role and boundary accurate
- Method useful without disclosing attack paths
- No open vulnerabilities or control gaps exposed
- Outcomes have approved units and scope
- Diagram is abstract or clearly illustrative
- Logos and partner roles approved
- Final page has a review or withdrawal trigger
Use a two-person release test
Before publication, ask one operational reviewer and one communications reviewer to assess the draft independently. The operational reviewer looks for details that could reveal architecture, locations, vulnerabilities, access paths, staffing patterns or incident timing. The communications reviewer checks whether the remaining story still proves a useful capability.
Give each statement one of four outcomes: publish, generalise, move to controlled evidence or remove. Do the same for diagrams, filenames, image metadata and alt text. Then read the combined page as an attacker might. Several harmless facts can become sensitive when joined together. Record the approved version, reviewers and withdrawal trigger. If the system changes, the customer changes its disclosure position or a related incident occurs, reassess the page. This approach preserves a credible project story while treating operational security as an ongoing responsibility rather than a one-time legal check.
Creatif Work builds engineering websites and evidence systems that respect information boundaries. Our website service can create public, tender-only and controlled content routes, while our guide to defence website information control applies similar principles to sensitive supplier work.