Physical Layer
How it actually runs: physical mechanisms and systems — servers, software, procedures — execute the logical workflows, acting on data. (SABSA physical layer.)
Breaking Down Each Concept
Each concept below sets out what it is, exactly what an architect needs to do to establish it well, the inputs it depends on, the outputs it must produce, and the mistake most likely to undermine it.
1. Physical System
What it is: the tangible components — hardware, software, infrastructure and procedural elements — that implement security mechanisms at the physical layer, providing the concrete implementation foundation for services operating at the logical layer.
What you need to do:
- Identify the physical system as the tangible infrastructure that will actually host the mechanisms the logical layer specifies.
- Map many-to-many where it genuinely exists: several systems may together deliver one logical service, and one system may support several mechanisms.
- Keep the mapping from logical mechanism to physical system explicit and current. This is the join that turns architecture into an operable estate.
- Assess physical systems for resilience, capacity and lifecycle separately from the logical design; the logical layer doesn't change when a system is upgraded, but the physical mapping does.
- Involve operations and engineering at this layer — the physical layer is where architecture meets what can actually be built, run and supported.
Inputs: the logical mechanisms it must host, the organisation's technology standards and estate.
Outputs: an identified physical system, or systems, capable of executing the mechanisms it is mapped to.
Watch for: a physical system chosen before the logical mechanism was properly specified. The tool then quietly redefines the workflow instead of the other way around.
2. Physical Mechanism
What it is: the concrete execution environment — servers, network devices, software modules, or human-run procedures — that realises the logical workflow, acting on data at the SABSA physical layer.
What you need to do:
- Identify the concrete execution environment that will actually realise each logical mechanism.
- Specify how the mechanism processes data technically — encryption, validation, logging, or whichever technical means apply.
- Map the physical mechanism explicitly back to its logical parent, so a change in implementation technology doesn't silently break the traceability chain.
- Expect variation by technology choice, and expect a single node to sometimes execute multiple mechanisms — physical reality is messier than the logical model, by design.
Inputs: the logical mechanism it realises, the available technology and procedural capability.
Outputs: a defined physical mechanism, mapped to its logical parent and ready to be decomposed into sub-mechanisms or run directly.
Watch for: physical mechanisms documented only in vendor configuration, with no link back to the logical mechanism they were meant to realise. The traceability chain breaks exactly here more often than anywhere else.
3. Physical Sub-Mechanism
What it is: the physical or procedural component that executes the logical sub-process defined by its parent — a specific encryption library, a microservice container, or a manual approval desk handling review tasks.
What you need to do:
- Identify the specific physical or procedural component that executes one logical sub-process.
- Keep it single-purpose and testable by input and output, so it can be verified in isolation during an audit.
- Map it explicitly back to its logical sub-mechanism so control testing can trace a finding to a specific, real component.
Inputs: the logical sub-mechanism it realises, the specific technology or procedure available to execute it.
Outputs: a testable physical sub-mechanism, ready to be delivered by a product at the component layer.
Watch for: physical sub-mechanisms that exist in practice but were never mapped back to a logical sub-mechanism — untraceable technical debt that audit will eventually find the hard way.