We have all heard that compliance is not synonym to IT Security although that is true for any compliance body out there; what does it mean for your company, and how should you go about tackling the remediation project?
Lately we noticed a lot of companies starting multiyear compliance centric projects. Unfortunately too many of these companies are or will get to the point where their focus will diminish for varied reasons lack of resources, tight budget (going over budget), and most probably changes in the target compliance body.
As with almost anything in life the start of a remediation project is critical, this will set the direction, tone and expectations that the project team needs to maintain along the project. Most companies are approaching these projects with just one project manager and probably a part time IT Security pro. While having a project manager and an IT Security person on board from the beginning of the project is a good idea limiting it to only those two resources is as bad as it can get. The issues with this situation is that the project manager doesn’t understand the need for sequencing tasks and provisioning prior deliverables into the next work package, and the IT Security person most probably cannot articulate in project management what the project manager is missing…
By now you probably recognized one or more situations you’ve been through; so what is to be done?
Vernance has extensive compliance and security centric project management expertise. In our experience regardless of having to undertake a PCI-DSS, RegSCI, SoX, NERC, HIPAA, NIST, ISO27000 or other compliance body remediation or alignment project, the approach should be the same. All these acronyms are nothing but a fundamental baseline targeted to address what we normally call common-sense compliance. None of the standards will ensure security but all of them will ensure a foundation that a company can build on to achieve efficient security and effective risk treatment.
To better understand Vernance’s approach we need to say that industry compliance standards are meant to address common risks that are specific to that industry. Almost all if not all industry IT Security compliance standards have their roots in NIST/ISO27000 and then re-shaped to the industry specifics (read specific risks). With this said and understood it is almost a simple conclusion that instead of trying to address punctual compliance requirements we should address risks (risk treatment= intent of the requirement) and if we do a good job there then compliance will come with it naturally.
In other words being compliance doesn’t mean you are secure but being secure means that you are at least 95% compliant.
We know this can be confusing for some and we are here to help!