The basic principle I have in mind and that I have applied is much like how a squirrel lives its life (at least, where I am from).  The squirrel spends its entire year gathering nuts to sustain it through the long, harsh Chicago winters.  When that time of year comes, it is able to stay safe and secure in its home reaping the rewards of year-round work.  The squirrel who waits until November to start gathering is going to have to frantically prepare, and there is a good chance it won’t survive.

That’s kind of a corny metaphor, but it’s shockingly relevant.  Thinking of the Midwest squirrel in general, many squirrely IT guys get charged with the task of passing annual compliance reviews/certifications – be it PCI, ISO, SOC, etc.  The processes are often VERY intensive, and, if you are going through a true audit, often require not only paperwork but proof that you have been working hard all year long to live the life you were expected to.

What goes into one of these audits?  Typically, it can consist of a few categories:

  • Policy Review
  • Training Review
  • Security Testing
  • Audit Analysis

Some can also include financial audits/reviews, but that’s a bit redundant as you can apply some of the same methodologies I’m discussing in other areas as well.

When it comes to policy review, there are three key factors to consider:

    1. Do you have policies to cover every aspect of your business as applicable to the framework in which you are being certified?
    2. Have you recently reviewed your policies to ensure they are accurate, up to date, and cover your business appropriately?
    3. Can you prove they are enforced?

There is absolutely no reason to wait until the day before your first snow (audit) to review these policies, but that almost always is the case.  Looking at something like PCI, for example, there may be the requirement for 50+ different policies to be presented – everything from employee handbooks to disaster recovery.  This can amount to hundreds of pages of review – why do it all at the same time each year?  Just because your smartest IT guy, perhaps with the help of a compliance officer, has been tasked with completing the task, that does not mean they can – or often should – be the sole voice in policy review and creation.  This often involves resources from operations, client services, and HR.  Why not hold quarterly policy reviews, where a portion of policies are reviewed?  Maybe it’s monthly to be more spread out, or even bi-weekly?

It’s important to note that some things can often change.  For example, many DR policies are written around the conception that your operations are 100% brick and mortar, and your servers are located at your corporate headquarters.  Did you send all of your agents home in the last year?  Did you move to the cloud?   These things can greatly affect your plan.  When you make the shift, maybe part of your change management process would dictate that you update your DR policies WHEN THE CHANGE happens – don’t let it be an afterthought down the road.  Also, the point of these policies is to protect your customers.  The policies shouldn’t be an afterthought – they need to be a part of life!  Therefore, if you didn’t really think about a new DR policy when you completely revamped operations – is the DR something you really follow, or just something you have on paper so you can check off a box on your audit?  Can you provide DR to your customers?  If you can’t, what else can’t you do?  Can you protect their data?  Can you notify of a breach?

Finally, how are these policies being enforced?  If you have a penless and paperless environment, are you only checking on this once a year?  If you are doing things properly, this is something you are very vigilant about, and you have probably written up at least 1 employee in the last year for an infraction.  It’s ok to admit someone broke the rules as long as you can prove you were monitoring for it and took appropriate action when it happened!  Make sure your HR department has a way to quickly and easily pull up evidence such as this, which proves you are monitoring and enforcing.

If you’ve gotten this far, you are probably dreading how much longer this blog will be. The beauty of this principle is that my 3-item list can be reused for all the other items as the methods of preparation with only minor alterations.  The rest becomes simple once we’ve established these habits!

Training review – what is your training program?  When was the last time it was reviewed?  Can you provide proof?  Many security frameworks (i.e. PCI) require ongoing or annual training.  That doesn’t mean everyone has to be pulled off the phone at the same time once a year to sit through an 8-hour security course!  Auditors will often state that there are simple ways to accomplish ongoing training.  This may be signs on the walls, messages on their screens between calls (if your software supports it), and so on.  And most importantly – make sure this is documented and easily available come audit time!

Security Testing – Almost everyone fails their first one or two penetration or vulnerability tests by their auditors.  What really matters is how badly.  Are we talking 2 servers missing a patch, or do we have a firewall that is wide open and uses the factory default username and password?  Penetration and vulnerability tests should be run all year by the IT team and – you guessed it – logged!  Sometimes going an extra step or two above and beyond the requirements for testing can go a long way for completing this audit quickly.

Audit Analysis – You need to be auditing yourself!  Auditors audit you, obviously, but they want proof you are doing that job yourself.  Are you?  Can you prove it?  Log these audit reviews and have them ready.

I guess I’ll end on one final analogy.  We all knew (or were) that person in school who never really paid attention in class, and then, when the finals were looming, would give themselves a crash course, write answers on their hands, or do whatever was necessary to pass the test.   That’s not what this is supposed to be about.  Having that ISO seal or PCI stamp isn’t just to show you can make it through a yearly audit, but more so to prove that you are living the life/walking the straight line all year long!

 

Connect with the Author

Isaac Shloss

Isaac Shloss

Chief Technology Officer at Grupo NGN

Isaac Shloss is an Information Technology specialist with more than 20 years experience – almost exclusively focused on the Contact Center industry. The majority of his carrier has been spent managing the IT departments for large BPOs, including a top 10 US teleservices provider where he built the technology and telecommunications architecture needed to expand the small, regionally-based company to a large, multinational enterprise. Isaac was an early pioneer and administrator of the contact center platform now known as NGNCloudComm, and he is now a part of the manufacturer’s executive management team in the role of Chief Technology Officer. At Grupo NGN, he is focused on enhancing the user experience through education development, customer support, and implementation, and converting client’s business needs into standard product features. Isaac regularly speaks at conventions and webinars regarding both compliance and technological trends around the contact center industry.

Isaac is also heavily involved with PACE, an industry association dedicated to the advocacy and advancement of the customer engagement industry. Isaac is a member of our Compliance Officers Forum and Government Affairs Committee (GAC). Through the GAC, Isaac chairs the State Legislative Affair Counsel, where he tracks state-level legislation that affects our industry, calls the member base to action and drafts opinion letters to state lawmakers on behalf of the association when needed. Additionally, Isaac is PACE’s representative to the FCC, serving as a member of both the North American Numbering Council’s (NANC) and Numbering Administrative Oversight working group (NAOWG).