strongdm / comply

Compliance automation framework, focused on SOC2
https://comply.strongdm.com
Apache License 2.0
1.33k stars 248 forks source link

Marking items un-satisfied #77

Open dylanz opened 5 years ago

dylanz commented 5 years ago

I'm just starting here, and after initializing the project, I want to mark all items unsatisfied until I've had a chance to go through them all. I see there's a .Satisfied that determines if it is or not, but I can't tell for the life of me how to set that true or not. I guess my questions are:

joepurdy commented 4 years ago

@dylanz I opened a PR that would default newly initialized compliance projects to show controls as un-satisfied.

Just as a heads up in case my PR doesn't land in comply or you want to manually un-satisfy controls you can simply comment out the satisfies front-matter on all the policies and narratives that you haven't implemented.

For example, instead of this:

name: Organizational Narrative
acronym: ON
satisfies:
  TSC:
    - CC1.2
    - CC1.3
    - CC1.4
    - CC1.5
    - CC3.1
    - CC3.2
    - CC3.3
majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
---

Comment out the satisfies front matter like this:

name: Organizational Narrative
acronym: ON
satisfies:
<!-- satisfies:
  TSC:
    - CC1.2
    - CC1.3
    - CC1.4
    - CC1.5
    - CC3.1
    - CC3.2
    - CC3.3 -->
majorRevisions:
  - date: Jun 1 2018
    comment: Initial document
---

This will ensure comply doesn't register these criteria as satisfied. Once the policy is implemented you can uncomment the satisfies front matter and that will mark controls as satisfied.

dylanz commented 4 years ago

@joepurdy Boom! This is fantastic. Thanks for the PR and the heads up!

joepurdy commented 4 years ago

@dylanz just a heads up. I closed #79 in favor of an alternate approach in #85.

Basically I think since this mainly impacts new users that are still implementing the default template policies it's better to just make those default templates generate with the satisfies frontmatter commented out. That has the same effect as showing controls unsatisfied as adding new frontmatter like live: true|false.

And by making the change to the default templates it only impacts newly generated Comply programs. Had we merged #79 it would have led to a breaking change release where projects that weren't using the new live frontmatter suddenly register all controls as unsatisfied.

Just wanted to give you a heads up in case you ended up using a forked version of Comply based off my original PR that added the live frontmatter. I'd recommend switching back to upstream Comply and adopting the pattern of commenting out the satisfies frontmatter until a policy is customized and implemented in your organization.