# Security by sector

Interpret controls through sector-specific impact, dependencies and regulatory scope.

SecNet.Work | 2026.10 | 2026-10-21

The same “access control” protects different outcomes: patient care, production safety or transaction integrity. A sector label alone does not establish regulatory applicability; country, entity role, service and scope matter. NIS2 implementation and DORA financial scope require authorized assessment. These sector examples support decisions rather than confer compliance.

## Work boundary
Manufacturing, healthcare, finance, logistics, SaaS and energy examples. Authorized change procedures apply to real critical systems.

## Process

### 1. Define the business outcome
Describe the protected service and harm scenario in sector terms. Distinguish data and physical consequences. Do not hide different impacts behind one risk score.

Expected evidence: Service and impact record

### 2. Validate applicability
Review entity role, country, service type and contractual duties with authorized teams. Distinguish guidance from binding rules. A sector list does not replace entity-specific assessment.

Expected evidence: Dated applicability assessment

### 3. Choose controls through dependencies
Link identity, supplier, power and communications dependencies to the service. Assess control effects on availability and safety. Define sector-specific closure evidence for the same control.

Expected evidence: Dependency map and control test

### 4. Validate with the owner
Have service owners assess evidence alongside engineers. Test with a sector-specific sample and assign open work. Do not convert a control-test result into automatic regulatory conformity.

Expected evidence: Service-owner decision and residual risk

## One control, three perspectives

### Operator
How does the control affect the service?
Test business and safety impact of the change.
Evidence: Service test

### Auditor
What supports applicability?
Trace entity and service assessment.
Evidence: Authorized scope decision

### Leader
Which dependency creates shared risk?
Show shared failure points to the service owner.
Evidence: Dependency and risk decision

## Evaluate evidence

**Claim:** The critical service can continue.

**Weak support:** Two servers exist in the same region.

**Stronger support:** Service recovery was tested with identity, communications and supplier dependencies; shared failure points are recorded.

**Rationale:** Two components do not remove shared power, identity or supplier dependencies.

## Decision desk
A critical service has two servers sharing one identity and communications path.
Start: start

### start
First step?

- **Map service dependencies and common failures** (good)
  You examine how the service can fail rather than count components. Test alternate-path independence.
  Next: verify

- **Close because two servers are enough** (risk)
  A shared dependency can affect both. Continuity claims need service-level testing.
  Next: repair

- **Close without a rationale** (incomplete)
  Deferring an open issue is not closure evidence. Record the uncertainty, owner and next verification step.
  Next: revise

### verify
The backup channel uses the same provider infrastructure.

- **Record shared risk and test an independent path with the service** (good)
  You test real independence rather than apparent redundancy. Present residual risk to the service owner.
  Next: planned

- **Accept the claim without testing** (risk)
  The initial claim and observed result differ. Support closure with a repeatable check in the same scope, rather than a promise or ticket status.
  Next: revise

### repair
Critical-service priority is unclear during an outage.

- **Assess impact with owners and decide priorities** (good)
  Priority is not assumed from technical convenience. Record service impact and authorized decisions.
  Next: planned

- **Delete the earlier record and close** (risk)
  Deleting the earlier decision undermines learning and accountability. Link the new action to the prior record and keep the rationale and residual risk visible.
  Next: revise

### supported
This decision is supported by the evidence in the example. Verify closure conditions in your own scope.

### revise
The decision lacks support. Record the rationale and required evidence, then reassess.

### planned
A remediation path is defined. Keep the matter open until implementation and verification are complete.

## Worked example
Entirely fictional.
- Sector: Manufacturing
- Critical service: Example filling line
- Dependency: Remote maintenance gateway
- Scope decision: Plant + legal review
- Control: Time-bound access
- Service test: Approved maintenance window

## Closure checklist
- [ ] Applicability assessed beyond sector label.
- [ ] Service and harm scenario explicit.
- [ ] Shared dependencies reviewed.
- [ ] Service owner involved in closure.

## Sectors

### Manufacturing
Safety, production continuity and legacy controllers.
Maintenance windows are limited; supplier support may be critical.
Verify remote maintenance with approval and session evidence; no active test without plant approval.
A second supplier path to a filling line was found through passive flows and rule review.

### Healthcare
Continuity of patient care and confidentiality of health data.
Medical-device changes may need manufacturer and clinical approval.
Test device, clinical workflow and emergency access together; preserve ENISA procurement guidance’s healthcare scope.
An approved alternative workflow was rehearsed for lab-result transfer when an integration failed.

### Finance
Transaction integrity, critical services and third-party dependencies.
DORA and local regulatory scope are assessed by entity and service.
Connect separation of duties, service inventory and supplier exit to the same business service.
A payment service’s alternate provider shared the same identity platform, revealing a common failure point.

### Logistics
Continuity of shipment, routing and warehouse operations.
Field connectivity and mobile devices may be intermittent.
Test offline processing, resynchronization and wrong-delivery controls with synthetic records.
After a warehouse device reconnected, a test verified the same shipment was not processed twice.

### SaaS provider
Tenant separation, customer data and release security.
Shared infrastructure changes can affect many customers.
Test object authorization, release provenance and customer export against a specific version.
A synthetic test found that exports crossed tenant boundaries despite correct read permissions.

### Energy
Physical service, safety and regional dependencies.
Control center, field systems and communications may share a failure mode.
Assess independent communications, plant access and authorized recovery rehearsal through service impact.
A dependency review revealed that two communications lines shared one physical route.

## Official sources
- [NIST Cybersecurity Framework 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)
- [ENISA — NIS2 technical implementation guidance](https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance)
- [ESMA — Digital Operational Resilience Act](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora)
- [NIST SP 800-82 Rev. 3 — Final](https://csrc.nist.gov/pubs/sp/800/82/r3/final)

https://secnet.work/learn/toolkits/sector-security