However which way you look at this, GRC can be summed up in 5 simple steps. No matter what the area, you need to:
1. Have a policy that reflects your goals and make sure people know about it
2. Have a way to carry out the policy
3. Have a way to make sure the policy is being carried out
4. Have a way to find out how well the policy is working
5. Have a way to deal with the times the policy’s not being effective.
Many aspects of IT (and of business for that matter) fall into one or more of these 5 steps. To be honest, most of them fall under step 2…carrying out the policy, but over the years we’ve increased the number and diversity of tools and processes that carry out the rest of these steps.
Now I’m a security guy – so let’s think of this in security terms for a moment. In the early days of security, goals were simple – “stop the bad guys”. And they still are to a certain extent.
So we developed a bunch of tools that did precisely that…firewalls, antivirus are great examples. As computers started getting used more, the requirements became more complex, and sometimes conflicting, especially when security and performance butted up against each other. Bad guys worked out how to make their stuff not quite as obvious any more – so we had to develop more formal policies that mapped our goals to what we did. Also, what constituted “bad stuff” changed rapidly, as did technologies and the way people use, so we had to better keep tabs on what was going on and adapt what we were doing.
Over time, things have gotten more and more complex, and we’ve needed more and more stuff to carry out policy, and keep tabs on what’s going on. Also, the people who pay for this stuff, i.e. management, have had the audacity to start asking probing questions about where their money’s going. And don’t get me started on types of things we’re now being *required* to do from a security perspective by governments, partners and customers.
So, risks have gotten much more complex, our goals aren’t just about “stopping the bad guys” any more - add “keeping the auditor at bay”, and “singing for your supper” to that list – and the rules we need to play by have exploded.
Enter tools that will track all of these steps. Over 150 leading organizations are using Archer to set and communicate security policy, and show why the policy is in place from a regulatory standpoint. They’re also using Archer to define processes to carry verify and visualize that policy’s being carried out properly, and deal with those instances where things aren’t as they should be, like when a security incident happens, or an audit deficiency gets called out.
In the next post we’ll talk about how these principles extend beyond security and into the wider realm of IT
Comments