A lot of lingo gets tossed around in the compliance world: Criteria, Standard, Point of Focus, Narrative, Control Owner, Test of Operating Effectiveness, and on and on and on. One of the most common terms is a control. A succinct, well written control will be easy to "prove," or easy for an auditor to test. A poorly written control will confuse an auditor and lead to unnecessary back and forth. At Strike Graph, we are commonly asked, “What the heck is a control and how do I write one?”
If you search online, you will find many definitions of what a control is. Unfortunately they are very technical and confusing, and are not very helpful unless you are a compliance geek or an auditor. We advise our customers to think of a control as the process step you put in place to address or solve for a specific risk, or that succinctly describes a key cybersecurity action.
A control will follow a basic formula which answers:
In other words, a control includes an actor, an action, and a frequency. Sometimes the frequency is not included, but is tracked as a separate characteristic of the control in a spreadsheet or database. Some controls will be more complex in order to accurately describe the action or process, but the formula above is a solid starting point.
Auditors interpret controls literally, and they will generally test exactly what is stated in the control. An experienced auditor — learn how to select one here — understands that some controls have a bit of wiggle room, which, in audit lingo is called the spirit of the control. For example, if a control states that “All employees sign an Acceptable Use Policy (AUP) upon hire”, the auditor may be looking for signatures on paper in an HR file. However, if you have an automated HR task tool where all documents must be reviewed prior to moving to the next onboarding task, it is likely that no signature will be collected. The workflow is such that they couldn’t move on in the onboarding process until they read the AUP. The spirit of the control is that all new hires have acknowledged they have read the AUP, whether there is a signature present or not.
Controls are generally in place to address a risk. For example, if you don't change the oil in your car on schedule, there is a risk that you will damage the engine. The control is that the oil is changed every 12 months or 6,000 miles by a mechanic. To prove that the control happened, you have a receipt showing the date, the type of oil used, and the make, model and mileage of your car. From the receipt, an independent party can confirm that the oil was changed, on schedule.
“Annually, the CTO reviews and re-approves security policies.” This control is too vague - exactly which policies? Do you have to list each policy that requires an annual review? Not really, but it wouldn't hurt. A more concisely wording control may be: “Annually, the CTO reviews and re-approves the security policies related to Change Management and Logical Access.”
There’s nothing worse than having an auditor fail a control because you didn't intend for everything implied within it to be tested!
You have a small team of developers and due to the size of the group, they have to wear many hats. As VP of Engineering, you mandate that any code that enters production is reviewed, tested and appropriately merged. To ensure that no rogue code enters production you implement a control that all code is reviewed and approved and that if one developer creates code, a different developer will test it. You also have a control stating that no developer can merge their own code.
The Strike Graph solution comes with an audit-proven library of controls that can be used or tailored for your audit. You don't have to create controls on our own! As a bonus, the controls in our library span various levels of maturity, from manual paper based to fully automated controls.