Help: Our auditor wants a control gap report, but the tool only shows current state.

That's a tricky request from your auditor. I don't think Secureframe tracks that historical gap data by default, since it's focused on getting you compliant now.

Could you use the evidence you've already uploaded? Maybe pull the dates on your earliest policy documents or system screenshots to establish a timeline of when controls were first implemented. That would at least show what wasn't in place before a certain date.

Out of curiosity, are they asking for this to gauge the tool's effectiveness, or to understand the initial risk?

You've hit on a classic pain point! Secureframe really is built to show your present posture, not document past deficiencies in a pretty report. That "before" snapshot isn't a standard feature.

What I usually recommend is using the "Activity Log" or "History" tab (the exact name varies) for each control. If you click into a control that's now marked compliant, you can often see the date when its status first changed from "Not Started" or "Failing" to "Passing." You'd have to compile that data manually, but it creates your timeline. For your AWS config example, the evidence history for that integration should show when it was first connected and passed its initial scan - anything before that date is your "gap."

It's a bit of a manual slog, but presenting that compiled timeline with screenshots has satisfied auditors for me in the past. They just want to see you understand the starting point.

This is a very common hurdle when starting out. Secureframe, like many compliance platforms, is built as a remediation tool, not a historical documentation system. Its primary function is to close gaps, not chronicle them for audit trails.

The feature you're looking for doesn't exist in a single-click report. For your AWS config example, you're forced into a manual reconstruction. You'd need to examine the evidence history for each relevant control to find the date of first successful verification. Any period prior to that date is, by definition, a deficiency. Compiling this into a report means exporting your control list and manually adding a "Date Implemented" column based on that history data.

It's tedious, but that manual compilation is often the only way to satisfy the auditor's request. It demonstrates you've done the forensic work to understand your starting point.

Of course the shiny new platform doesn't track your past mess. They're selling you a mop, not a security camera.

You're trying to get blood from a stone. There's no magic export for a state that was never recorded. The real answer is uglier: you need to build the "before" picture from whatever evidence you *do* have outside the tool.

For your AWS config example, you'd need to manually pull old CloudTrail logs or Config snapshot history from three months ago to prove a rule wasn't enabled. The auditor isn't asking for a tool feature, they're asking you to demonstrate you actually know what your environment looked like. Start digging in S3 buckets for old data, not in Secureframe for a report that doesn't exist.

Welcome! That's a smart question, and you're right to be looking for a clearer path. The platform is really geared toward your current posture, so that specific "before and after" report isn't a standard feature you're missing.

Building on your AWS config example, the most practical approach is usually to use the evidence history within Secureframe itself. If you navigate to a control that's now passing, look for the history or activity log on that specific item. The date when evidence was first uploaded or a check first passed becomes your "implemented on" date. For the period before that date, you'd note the control as a gap. It's a manual process, but it directly uses the data you already have in the tool.

Your auditor is likely trying to understand the scope of work you undertook, which is a reasonable request even if the tool isn't built for it. Pulling together a simple spreadsheet listing key controls with their "date remediated" from Secureframe's history might be the simplest way to meet their need. It's a bit of legwork, but it's defensible.