Skip to content
Notifications
Clear all

How do I handle a control that Secureframe doesn't have a template for?

3 Posts
3 Users
0 Reactions
0 Views
(@annaw)
Reputable Member
Joined: 3 weeks ago
Posts: 184
Topic starter   [#24675]

Hi everyone! I’ve been deep in a SOC 2 Type II audit prep with Secureframe for a few months now, and overall, it’s been a huge help for streamlining evidence collection and managing our compliance program. 🚀

But I’ve hit a snag. We have a specific physical security control for our main office that our auditor requires, but I can’t find a matching template or built-in control in Secureframe’s library. It’s a pretty custom process involving our building management's access logs.

My current workaround is to:
* Use the "Custom Control" feature to create a placeholder.
* Manually upload our evidence (PDF reports from building security) as attachments.
* Track the review and testing tasks via manual reminders in our project tracker.

This feels... clunky and risks breaking the nice, automated workflow Secureframe is so good at. I’m worried about losing visibility for this control during the audit.

So my question for the community is: **How have you handled non-standard or missing controls?**

Specifically:
* What’s your process for documenting and evidencing them?
* Do you use the Custom Control feature, or do you map it to an existing control that’s "close enough"?
* Any tips for keeping these custom items on track for reviews and renewal?

I’d love to hear how others in similar boats have navigated this. Sharing your real-world examples would be amazing!

happy evaluating!



   
Quote
(@hannahd)
Estimable Member
Joined: 3 weeks ago
Posts: 101
 

Your workaround is the standard approach for a reason - it works. The "clunky" feeling means you've identified the real problem: process gaps.

Don't map it to a "close enough" control. That creates a mismatch between your documented process and the actual evidence, which an auditor will spot. The Custom Control feature exists precisely for this.

To tighten it up, treat the custom control exactly like a native one. Define the test frequency, assign an owner, and set recurring calendar reminders in Secureframe's description field. This keeps the task tracking inside the platform, not in a separate tracker. Your visibility stays intact if you use the tool's own fields as your source of truth.


—hd


   
ReplyQuote
(@first_timer_evan)
Estimable Member
Joined: 3 months ago
Posts: 142
 

That workaround sounds like exactly what I'd be doing, so it's helpful to hear you confirm it's the standard path. I'm starting my own SOC 2 prep soon and this is one of my big fears.

I've heard some people create a separate, simple "evidence log" spreadsheet for just these custom controls and link to it in the Secureframe description field. That way you keep a central list outside the platform, but the auditor still has a direct path from the control to the master list. Have you considered something like that, or does it just add another layer to manage?

Do you find the Custom Control feature integrates well enough with reporting and dashboards? Or does it kind of live off to the side?



   
ReplyQuote