Controls
Controls are one of the core building blocks of compliance management in Openlane. A control represents a specific security, privacy, or operational requirement your organization implements to meet compliance standards and manage risk: it defines what needs to be done, how it should be implemented, and how it will be tested or verified.
Policies set the direction by defining the overall goals and expectations for managing risk; controls are the practical implementation, the actual mechanisms and processes (approvals, verifications, monitoring systems, security protocols) that carry those expectations out.
Subcontrols
Some controls are too broad to implement or test as a single unit. Subcontrols split a control into smaller pieces that can each be implemented, tested, and verified on their own, while keeping the parent control as the thing your framework maps to.
Take a broad access control requirement: the encryption configuration, the approval workflow, and the physical badge system might all live under it, but they're owned by different teams and verified in completely different ways. As three subcontrols, each piece gets its own implementation and its own verification, and the parent control rolls them up.
FAQ
What's the difference between an implementation and evidence?
The implementation describes how the control operates; evidence proves it operated during the period. Auditors want both: the narrative and the artifacts that back it up.
Do I need an implementation for every control?
An implementation is intended to make Openlane a functional system, not just a documentation repository. When you track what you actually do alongside the requirement you have to satisfy, you're more aware of what you have to adhere to and why.
Who should own an implementation?
We recommend the person who actually runs the process rather than the compliance lead, because they'll know when reality drifts from the write-up. Drift between the two is the most common audit finding, and the person doing the job always knows the criteria and inputs best.
When should I split a control into subcontrols?
When its components have different owners, different implementation types, or different verification methods. If one person implements and one test verifies the whole control, a single implementation is simpler; don't split for the sake of splitting.
Do subcontrols map to frameworks separately?
No, framework mapping happens at the control level. Subcontrols organize the work underneath a control; the parent is what satisfies the requirement.
Can a subcontrol have its own implementation?
Yes. That's the point: each subcontrol carries its own implementation narrative and verification, independent of its siblings, and evidence collected for it demonstrates exactly that component.