Save Yourself a Boatload of Hassle: Document

Remember the “Scantron” sheets that you had to fill out in school for taking standardized tests — you know, the ones where you had to fill in the circle with a No. 2 pencil to mark your answer?

Now imagine you’re watching someone take a standardized math test — you watch as they spend 15 minutes calculating the answer to a complicated problem. They painstakingly work out the correct solution on the provided scrap paper, they check and double-check their answer to make sure it’s right, and they confidently circle the answer on the scrap paper. Then, after doing all that, they move on to the next problem without filling out the little circle on the answer sheet.

Can you imagine that happening? Maybe by accident. But can you imagine someone doing that on purpose? Of course not. After all, what kind of chump would do all the work to get to the right answer, but then purposely ignore the part where they actually get the credit? Are they more likely to pass the test because they actually knew the right answer but chose not to mark it on the answer sheet? No. No matter how much time they save by not filling in the little circle, all the time they spent on the problem was wasted. No matter what their rationale for skipping that part, the end result is the same: They fail.

Don’t Be That Guy

However, would it surprise you if I told you that in enterprise, a situation almost exactly analogous to this one happens all the time? It’s true. I participate in a lot of audits — providing guidance to firms going through audits, working with vendors building audit products, and (sigh) actually conducting audits themselves. I can tell you for a fact that the normative case is something — some process, some procedure, or some security control — in an organization where they’re “doing the right thing” but don’t have the documentation to back it up. In the pithy words of a now long-retired colleague, “If there’s no document, it didn’t happen” — at least from an audit point of view.

In my opinion, this situation is (to put it frankly) inexcusable. Taking into account only the compliance impact of the situation, it’s worse to have a functional control that’s undocumented than it is to not have the control at all. Why do I say that? Because having the control means the company has invested all the money and time to do the “hard part,” but they’ve wasted that investment by not doing the “easy part” and actually making their investment have value. Like the kid with the standardized test, they’ve done all the work, but failed to get the credit.

Now, some people might argue that from a security perspective, the company with the appropriate control (whether it’s documented or not) is better off than they would be without the control because they have lower risk. That’s true … but that’s one of the many differences between compliance and security: From a security standpoint, they are better off; from a compliance standpoint, not so.

Step #1: Inventory and Document

Of course, there’s a reason why firms find themselves in this situation. There are, after all, tons of regulations on any given organization’s plate: tons of individual clauses and sub-requirements that organizations have to address, implement and document. This situation isn’t getting any easier any time soon — new regulations spring up like weeds nowadays, so keeping ahead of them can be (and usually is) someone’s full-time job.

Without some kind of framework to make sure that all the requirements are addressed, of course there are going to be areas that get overlooked. No matter how much work an organization does to implement the right controls, the fact of the matter is that the documentation part is hard: It usually involves different folks than those doing the technical work, it’s often an afterthought, it needs to keep pace with new/updated regulations, and it needs to be constantly validated against what’s actually implemented in the field.

The logical end state of this is that the documentation piece requires an organized, consistent and methodical approach in order to be useful during an audit — to make sure controls are documented, that the documents stay updated, and that they actually match what’s implemented technically.

One approach that works well is to systematically inventory all of the controls associated with the regulation in scope for your organization. Once you have that inventory, go through and index all your policies, procedures and standards, and make sure that there’s at least one document for each required control. Keep track of that index so that you can quickly show an auditor specifically which documents tie to which controls, and save this artifact for when you’re actually in an audit situation.

If you support multiple areas with different policies, procedures and standards (for example, different business units with different requirements), note areas where control implementations differ. However, at the very least, make sure that every area has one governing document per control. Any place where you don’t have a document, spawn a work effort to create one. Hand off responsibility of that effort to the subject matter experts who oversee the control and track their status to make sure they produce the artifact in a timely manner. Once the documentation is created, update your inventory accordingly.

Step #2: Maintaining the Inventory

Of course, putting the inventory in place is only the first step. Once it’s there, you’ll need to make sure it stays current. Make sure any newly identified regulation goes through exactly the same process of inventory and mapping the way you did with the original requirements you identified.

If you’re the person responsible for the inventory, make it your business to keep abreast of any audit activity going on in your organization. If an auditor has a hard time locating a particular piece of documentation, note it and address it in your inventory. If an auditor disagrees that a particular document is sufficient to pass regulatory muster, note that and address it too. If an auditor finds you non-compliant with a particular requirement because of missing or unclear documentation, note it and address it.

On a periodic basis, go back through your inventory to make sure that the documentation hasn’t “gone stale” — in other words, that what you have documented actually matches what folks are doing in the field. Enlist the same subject matter experts that originally helped create the documentation to verify that it’s still accurate. After all, things change — so expect to encounter situations where processes have evolved leaving the documentation inaccurate.

If this sounds like a lot of work, that’s because it is. There are some automated tools out there that can help you automate the creation of this inventory (for example, tools in the GRC space), but whether automated or manual, make sure it gets done. Making sure that your organization gets appropriate credit for all the hard work you’re doing shouldn’t be taken lightly.