Make explicit when a control builds on an earlier control

[ericcornelissen]

I went through to checklist for a project and found myself thinking "haven't I answered this already" several times, in most cases this happened because a control build on an earlier one (e.g. OSPS-VM-03.01 and OSPS-VM-02.01). It would be very helpful if this was explicit and I'm not left guessing. And no, the numbering in the IDs isn't clear enough for someone not involved/familiar with the project (in fact, I'm only assuming there's some kind of logic by which I could have told one builds on the other).

[funnelfiasco]

the numbering in the IDs isn't clear enough for someone not involved/familiar with the project (in fact, I'm only assuming there's some kind of logic by which I could have told one builds on the other).

There's intentionally no logic beyond "increment the number when a new control is added". We made this choice to avoid mass-renumbering controls when one is added or removed, which we felt would cause more confusion than the route we chose.

I agree that we should make these related issues more obviously tied together, but I'm not sure about the best implementation. That's something we'll have to think about.

[eddie-knight]

This may be a place where our mixed-use approach between control objectives & assessments is backfiring. Assessments within a control should build on each other, with the control objective describing the overall goal. But right now we have a bit of complexity added by using MUST statements in the objectives, instead of it being a high level statement. So in some cases we need to create a parallel control objective because the first one doesn't quite hit all the needs.

It'll be a comprehensive activity to adjust that for a future release, but I suspect it's the only approach that will clear this up.