Think of it like building a compliance sandwich. The layers stack up.
**Policy:** This is your rulebook. It's the high-level statement. "We will encrypt all customer data at rest." It's written in plain English in Secureframe.
**Control:** This is the specific, actionable requirement that enforces the policy. It's the checklist item. "Verify that all S3 buckets use AES-256 encryption." Secureframe maps these to frameworks (SOC 2, ISO 27001, etc.).
**Evidence:** This is the proof you attach to the control. It's the screenshot, the AWS config scan result, or the procedure document. No evidence? The control fails.
Example for Access Management:
* **Policy:** "Access to production systems is restricted."
* **Control:** "Review user access quarterly."
* **Evidence:** A generated report from your IDP showing the last review date and signed approvals.
Without evidence, a control is just an unchecked box. Policies without controls are just documents nobody implements.
Pipeline plumber, not a devops magician.
That sandwich analogy is the best explanation I've seen, thanks! It really clicked for me. So the evidence is basically the "receipt" for the control's requirement.
A quick question from someone new to this: who usually writes the policy vs. who sets up the control in Secureframe? Like, does a security person write the policy doc and then an ops person finds the right technical control to match it?
That sandwich analogy is perfect for visualizing it, thanks! So the policy is basically the "why" we do it, the control is the "how," and the evidence is the "see, we did it."
I have a newbie question, maybe you can help. You said the policy is written in Secureframe. Does that mean you're writing it from scratch in their tool, or are you uploading a policy document your company already has? And if you upload your own, how do you link it to the controls in the platform?
The "compliance sandwich" analogy is a great mental model, especially for explaining to stakeholders who aren't immersed in this daily. You've nailed the core hierarchy.
One nuance I'd add from working with the platform: the relationship between control and evidence isn't always a simple one-to-one. A single control, like "quarterly access reviews," can require multiple pieces of evidence to be considered fully satisfied. You might need the review procedure document, the actual report output, and maybe a sign-off email. Secureframe's interface lets you attach multiple evidence items to a control, which is crucial because auditors often want to see the full chain, not just a single screenshot.
Also, the phrase > Policies without controls are just documents nobody implements. is spot on. I've seen companies waste months polishing policy wording in a vacuum, only to realize they have no automated or manual controls to actually demonstrate compliance. The tool really forces you to think in reverse: start from the framework controls you need to satisfy, then craft or adapt your policies to justify them.
Prompt engineering is engineering
That sandwich analogy is okay, but the real world gets messy fast. Your example is clean, but policies written in Secureframe's plain English often don't match the exact wording of your company's internal policy documents. Then you're stuck with two "truths" and have to explain the mapping to an auditor.
Also, the statement "No evidence? The control fails." is technically true, but incomplete. The bigger gap is stale evidence. You can attach that quarterly access report from last year, the control is green, and everyone moves on. The policy is technically being "enforced" with outdated proof. The real failure is when the system doesn't flag that evidence as expired.
Lisa M.
Finally, someone talking about the mess. The stale evidence point is the real killer. I've seen controls stay green for months because someone attached a PDF from the previous audit cycle and the system just ticks the box. It creates a dangerous illusion of compliance.
On the policy mismatch, you're right, but I take a more aggressive stance. I don't let the team write a separate policy in Secureframe at all. We upload our actual, approved corporate policy document as the evidence *for the policy itself*. Then we map the platform's canned controls to our real policy statements. It's extra work on the front end, but it avoids the "two truths" problem you mentioned. The auditor sees our document, not Secureframe's paraphrasing.
The whole model breaks down if you treat these platforms as the source of truth instead of a tracking system for your actual truth.
keep it simple
Totally feel you on the stale evidence problem. That "green" status can be dangerously comforting. I've started adding calendar reminders for myself *outside* the platform for critical evidence refreshes, because you can't always trust the tool to flag it.
Your method of uploading the actual policy doc is smart. I do something similar but take it a step further: I paste the exact clause from our policy into the Secureframe policy description field, and *then* link the full PDF as evidence. It gives the auditor the exact wording right there, plus the source.
My one gripe is the mapping work. When a canned control is even slightly misaligned, you're stuck creating a custom one, which sometimes breaks the automated evidence collection. Ever run into that?
Data is the new oil - but it's usually crude.
The sandwich analogy is solid for the basics, but the real value comes from how you connect the layers in practice. Your example with the IDP report is spot on, that's the exact evidence type for that control.
One thing I'd add from running compliance for my team, a good control description in Secureframe should almost read like a test case. "Verify all S3 buckets use AES-256" is clear, but "Generate an AWS Config report showing all S3 buckets have default encryption enabled with AES-256" is better. It tells you *exactly* what evidence to produce, closing the loop tighter.
Absolutely. That's the only way I'll write them now, after getting burned once. A vague control description leads to a frantic scramble when someone inevitably provides proof of the wrong thing.
Your "Generate an AWS Config report..." example is perfect. I take it further and build that expectation into the control's metadata when I can. If the evidence type is a 'Screenshot', I'll note the exact CLI command or console path in the description. If it's 'Automated,' I'll specify the exact output format from the collector.
It turns the control from a subjective checklist item into an objective, repeatable test. The downside is it makes the platform's pre-baked controls, with their fluffy descriptions, almost useless. You end up rewriting most of them.