Hi everyone! I've just started using Tugboat Logic at my new job to help with our SOC 2 audit, and I keep seeing the term 'control' everywhere. I think I get the gist, but I want to make sure I understand it correctly before I start mapping things.
In Tugboat's world, is a 'control' basically just a specific rule or safeguard we have to follow? Like, would "all laptops must be encrypted" be considered a single control? I'm trying to figure out how granular they are meant to be.
Also, how do controls relate to the 'requirements' and 'policies' I see in the platform? Are they the same thing? I'm a bit worried about setting things up wrong from the start. Any simple examples from your own experience would be super helpful! 😅
Thanks in advance for helping a newbie out.
Yeah, you're spot on. "All laptops must be encrypted" is exactly the right level of granularity for a single control. It's the specific, actionable thing you need to implement and test.
The way it clicked for me was thinking of the hierarchy: a *requirement* (like from SOC 2) is the "what". A *policy* is your company's internal statement that says "we will meet that requirement." And then the *control* is the actual "how" - the concrete safeguard or procedure that makes the policy real. So you might have one policy covering several related controls.
Don't sweat setting it up perfectly the first time. You'll refine them as you gather evidence. I started by mapping controls directly to our existing technical configs, like our Terraform modules for encrypting S3 buckets.
K8s enthusiast
Precisely correct on the granularity. That laptop encryption example is a textbook control. The nuance I'd add, particularly in a cloud context, is that a well-defined control should map to a single, testable assertion. You shouldn't have "and" in the statement.
The hierarchy user1021 described is accurate. Where I've seen teams struggle is conflating the technical implementation with the control itself. For instance, you might have a control stating "All object storage buckets must be configured to reject public ACLs." That's the control. The evidence could be a Terraform module, a specific AWS Config rule, or a manual screenshot. The control is agnostic to the tooling.
My advice: start by writing controls as simple, verifiable statements. If you can't conceive of a piece of evidence that proves it true or false, it's not granular enough. You'll merge or split them later as you map to your actual systems.
Boring is beautiful
That point about a single, testable assertion is key, especially when you start automating evidence collection later. If you write "All laptops must be encrypted *and* have a screen lock," you now have two tests to run and two potential failure points mashed into one control.
In our K8s setup, we learned this the hard way. We had a control that read "Cluster nodes must be on a supported version *and* have automatic security updates enabled." When a node fell behind on versions but had updates enabled, the control status was a meaningless "partially compliant." Splitting it into two separate, clear yes/no controls made reporting and fixing issues so much simpler.
Exactly! That "partially compliant" status is a nightmare for dashboards and automated alerts. Your K8s example is perfect.
We had a similar pain point with a CI/CD control. It was originally "All production deployments must require a successful build *and* pass security scanning." When the scanner was down for maintenance, the entire control showed as non-compliant, even though all builds were still required. Splitting them gave us clean signals - we could see the build requirement was always met, and the scanning failure was its own, actionable item.
It makes automated evidence collection so much cleaner too. Each control can map to one specific check or script.
Pipeline Pilot