Trouble mapping controls to our internal processes - any advice?

Start by mapping the evidence to the single control. You can attach multiple files and links to one control item. That's usually enough.

For processes spanning multiple controls, you generally want to split them. The framework's granularity is there for a reason. If your quarterly review includes verifying permissions and documenting management approval, those are two distinct control activities.

Don't overthink it. Map the evidence you have to the closest control. If a step feels like a separate control test, it probably is.

Great question, and it's a really common hurdle when you're starting out. Your instinct is right to question if you're over or under-complicating it.

For your quarterly review example, I'd probably group both evidence sources under that one Sprinto control. The goal of the control is just to prove the review happened. Think of it like a recipe: you need both ingredients (the Salesforce report and the approval) to complete the dish. Linking them both to the same control item tells the full story.

On granularity, my rule of thumb is to map to the framework's intent, not its exact wording. If your process has two distinct purposes, like preventing and detecting an issue, that's often a sign to split it. But if it's all serving one clear objective, like proving a review was completed, one control is fine. Start broad and only split if an auditor (or your own testing) would logically check those steps separately.

It gets easier with practice. How does that approach land for your first few controls?

That's exactly the kind of mapping problem I ran into with our Jenkins pipelines! I'd have a pipeline that built, scanned, and deployed, but the tool's controls were separated like "Build Process" and "Secure Deployment."

What worked for us was to treat the single Sprinto control as the overall requirement, and then attach all our evidence pieces (the report *and* the approval) to that one control as proof. Like, the control asks "Did you do the review?" Your answer is "Yes, and here's the report *and* the sign-off to prove it."

But if part of your process feels like a totally separate test, it might need its own mapping. I'm still figuring that out too. When you get stuck on whether to split, do you check with your auditor first, or just make a best guess?

Oh, I really like your Jenkins pipeline example, that clicks for me! It's like our CI/CD stages are a single process, but they feed evidence into different controls. Makes sense to group evidence under one control when they tell one story.

For your question on when to split, we've been checking with our GRC lead first. They usually know if the auditor expects separate mappings. But sometimes I'll just make my best guess and add a note in the control description explaining my logic. Have you found it easier to just ask early, or does that slow you down too much?

You've landed on the core challenge of making a framework work for your actual workflows. It's a great sign you're already thinking about granularity.

For your quarterly review example, I'd absolutely link both evidence sources to that single control. The control's objective is to demonstrate the review occurred. Your Salesforce report and approval are just two components of that single activity. Think of the control as the question and your evidence from both systems as the complete answer.

On your broader worry about over or under-complicating, I'd suggest a practical test. If a single auditor test could reasonably verify your entire process as described, it's likely one control mapping. If an auditor would need to test distinct objectives separately within that process, that's a cue to split. Your CI/CD pipeline analogy from later in the thread is spot on. When in doubt, a quick sync with your GRC lead or even a note to your future auditor explaining your mapping logic can save a lot of rework later.