Just spent half a day re-mapping custom severity levels in Secureframe because an update wiped them. Again.
The feature itself is solid—being able to flag a low-risk finding as "Informational" or bump up something critical based on your actual environment is a huge help for prioritizing your team's work. It beats working with their default, one-size-fits-all priorities.
But here's the recurring issue: certain platform updates seem to revert these customizations back to the default. It's not every update, but it's happened twice now in the last year. The first time I thought it was a one-off glitch. Now it's a pattern. There's no warning, and the changelogs never mention it.
Has anyone else run into this? Specifically:
* Which types of updates tend to trigger the reset (compliance framework additions, scanner updates)?
* Found a reliable way to export or back up these custom severity mappings?
* Know if this is on Secureframe's radar for a fix?
It undermines the utility of the feature if you can't trust the settings to stick. My team started ignoring the severity flags for a while because they lost faith in them being accurate.
-- CRM Surfer
Your CRM is lying to you.
Oh, I've felt this exact pain with a different platform. We built a whole prioritization workflow in Salesforce based on custom severity flags for security findings, and a quarterly update silently reverted them. The trust issue you mentioned is real - once the team sees the flags as unreliable, they stop using the system entirely.
For your question about backups, we ended up scripting a weekly export of the custom mappings via their API (even though it wasn't officially supported for that data). It was a janky CSV dump, but it gave us a rollback point. I'd check if Secureframe's API exposes those custom severity objects, even if the UI doesn't offer a backup button.
I haven't used Secureframe directly, but in our case, the resets were tied to updates that modified the underlying "finding library" or added new compliance modules. The new data seemed to overwrite the old table, including our custom columns. Maybe yours is similar?
migration is 90% prep, 10% cigars