Announcement

Collapse
No announcement yet.

Policy Documentation mapping

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Policy Documentation mapping

    So here’s my end goal:

    Relationship mapping of all policies, plans, guidelines, standards, and procedures in conjunction with mapping to control families of three compliance realms and to the specific controls within those realms. NIST 800-53r4, SOC2, and NIST CSF. This is supposed to allow others within the org to easily see the lines from the top down policies to a given procedure and allow for easier audits by directly list what applies to specific controls.

    I can apparently build entity relationship diagrams ERDs in our wiki so I’m going to see if that supports linking to the actual documentation. I think the specific control mapping would have to be its own independent matrix. I also think some sort of standardization of naming with a prefix would be prudent. Like all access control documents being AC-05-01 representing the family AC, 05 level (procedure), and the procedure #.

    So my question is: how have others approached this and had success?
    -
    Sandpaper

  • #2
    I'd say that it sounds like you are looking for a GRC tool, but since you may be familiar with those already, I have to ask... What is the difference between what you're looking for and a GRC tool?
    -AC

    ----
    Twitter: @AccidentalCISO
    Blog: https://www.accidentalciso.net/

    Comment


    • #3
      We have a new GRC tool that has the capabilities to do the mapping. I suppose what I’m asking here isn’t what tool you use, rather, tell me your story of implementation and presentation.

      How did you go about structuring the mapping and share that information back to the organization?

      Nobody will be logging into the GRC tool to view this outside of admins, so I need a good structure and presentation mechanism to share outward; something that can be easily followed top down and bottom up.
      -
      Sandpaper

      Comment


      • #4
        Ah, I see!

        My GRC tool is still Excel at this point. I'm hoping that will change next year, budget permitting. Sadly, nobody in my org really cares to see any data. They just want to know that the audit reports are available to give to customers.

        I'm interested to hear with others have to say on this topic. I could use some ideas as well.
        -AC

        ----
        Twitter: @AccidentalCISO
        Blog: https://www.accidentalciso.net/

        Comment


        • #5
          This is largely how we have approached it over the last few years.

          Some background: Big enterprise with on the ground operations in > 40 countries. Lots of resources we can use, but an incredibly complicated, diverse network of assets and accounts of all types. We get looked at by regulators globally, which brings all sorts of additional burdens to the teams in each of the countries. Our IS group is an enterprise shared service, so covers all the relevant stuff for all of that.

          All of that is to say that if there's something that can break the model you're talking about, we've found it. By walking head first into it. But the approach works really well if you get it flowing right.

          Couple of lessons learned:
          • Make sure you're granular in you're mappings. If you don't map across granular data points, the big picture across the GRC dataset loses all value. Stay granular and you can draw really useful conclusions long term about what relates to what and where you have gaps in the mapping.
          • Change management is a bitch. Keeping all of the mappings updated and accurate as you update policies, technology, controls, look at new regs, etc, is a lot of work. Plan for it to be bigger than you expect.
          • Have people responsible for owning things outside of you or your GRC people if at all possible and leverage them in your process. Whether it's control owners or policy owners or the technology owners, have stakeholders that have to sign off/review/challenge the mappings as you do them as part of a recurring process. It'll make your life easier long term because you'll have built in advocates and less push back when you want to make a change because you have a gap in your mapping coverage.
          • When it comes to off the shelf tools, find one that fits how you want to do it OR go with the underlying GRC data model of the tool you have. One of the worst things is to start fighting your own GRC tool as you get down the path. You end up with all sorts of compromises that make the change management part worse, crush your stakeholder engagement, and/or cause custom development against the tool which.. just yuck.
          • Refresh periodically (we do different refresh cycles depending of the risk in question for each thing)
          The first two above are really important and go hand in hand. You need to be granular to be meaningful, but the more granular you are the worse your change management is. Find the right balance for your org.

          Our presentation mechanism outwards ended up being a custom webapp we built to just publish the pieces of data our stakeholders needed in the prettiest, most accessible fashion possible. Keeping everyone out of your GRC tool is the right idea.


          Comment


          • #6
            Originally posted by joshlane View Post
            This is largely how we have approached it over the last few years.

            Couple of lessons learned:
            • Make sure you're granular in you're mappings. If you don't map across granular data points, the big picture across the GRC dataset loses all value. Stay granular and you can draw really useful conclusions long term about what relates to what and where you have gaps in the mapping.
            • Change management is a bitch. Keeping all of the mappings updated and accurate as you update policies, technology, controls, look at new regs, etc, is a lot of work. Plan for it to be bigger than you expect.
            • Have people responsible for owning things outside of you or your GRC people if at all possible and leverage them in your process. Whether it's control owners or policy owners or the technology owners, have stakeholders that have to sign off/review/challenge the mappings as you do them as part of a recurring process. It'll make your life easier long term because you'll have built in advocates and less push back when you want to make a change because you have a gap in your mapping coverage.
            • When it comes to off the shelf tools, find one that fits how you want to do it OR go with the underlying GRC data model of the tool you have. One of the worst things is to start fighting your own GRC tool as you get down the path. You end up with all sorts of compromises that make the change management part worse, crush your stakeholder engagement, and/or cause custom development against the tool which.. just yuck.
            • Refresh periodically (we do different refresh cycles depending of the risk in question for each thing)

            Some great points!

            I like joshlane work in a very large international company and we are still grappling with how to do this, it seems to be the holy grail of Governance and Compliance.

            We have started this year implementing a mapping in our global policies to some of the NIST standards 800-171 & 53, however it is left to the different home markets to flow it on into their Policy, Standards and Processes. We are yet to workout the best way, as we like you Sandpaper have 5 different frameworks to map.

            I feel for us the biggest issue is going to be change management. We believe the way forward for us is a good document management system (not in a GRC tool), looking at DOORS which will have the capability for us to link documents and controls at a very detailed level. This is my plan for 2020 anyway.

            Comment

            Working...
            X