Countless regulatory compliance and client requirements depend on clear and appropriate policies and procedures to demonstrate how organizations are conducting their business. Without defined policies and procedures, you face the threat of heavy fines from regulatory governing bodies, loss of business, or loss of data. As auditors, we find that many of our own clients struggle with understanding the organization of a policy, what does belong in a policy, what doesn’t belong in a policy, and the writing style and content of a policy.

What are Policies and Procedures?

Understanding how to write a policy starts with first understanding what a policy is. According to Merriam-Webster, a policy is “a definite course or method of action…to guide and determine present and future decisions; a high-level overall plan embracing the general goals and acceptable procedures…” In terms of our world, this means what employees must do or not do, directions, limits, principles, and guides for decision making – all representing mandatory rules that must be enforced. Simply put, it’s the law at your organization. To differentiate between what a policy is and what a procedure is you must consider policies to be what you do, and procedures are instructions on how you execute that policy.

Example Policies and Procedures

Companies collect, store, process and transmit a large amount of sensitive information – about their employees, business, and their clients. This information can be personally identifiable information such as credit card numbers, or social security numbers, patient records, company secrets and intellectual property, and more.

An example of a policy that would address the physical security of this kind of information would be something like this:

All visitors must sign in at the front desk in the Visitor Log and present two forms of identification, wear a badge the entire time they are on the property, be escorted by personnel throughout the facility at all times, and sign out when leaving the facility.

And the procedure for that policy would look something like this:

Front desk employee collects two forms of picture ID. Visitor is required to sign Visitor Log and include name, date, time-in, time-out, and reason for visiting. Visitor badges are issued by appointed personnel. They are easily distinguishable from employee badges. Visitor badges are collected by a front desk employee upon exit. Appointed personnel is required to escort the visitor at all times while on company premise.

Why You Need Policies and Procedures

As organizations, we need policies. We need defined rules. We mainly need them to control risks to our business assets, but to also have a common understanding and language to create consistency among the culture of our organizations. Imagine trying to train a new hire without a list of policies that give clear instruction for how to do a certain job? How can you successfully defend your actions if you don’t have a policy to refer back to showing that you did what you were supposed to do? Policies are also necessary for compliance with most regulatory and information security frameworks.

Creating a New Policy

There are several components that go into the creation of a new policy. The format and content requirements, policy approval requirements, annual policy review requirements (at a minimum), dissemination of a policy, enforcement of a policy, and the roles and responsibilities within a policy. Policies should have a standard format and structure that often include a title, who owns the policy, when the policy becomes effective, which version that it supersedes, and who approved the policy. The organization of a policy, as a general rule, includes the background and purpose of a policy, scope, the actual policy statement communicating what are the rules, roles and responsibilities of those that may be referred to in the policy, references to other policies or procedures that are interrelated, a glossary of any terms that were used, and a revision log showing the history of the review and update process of a policy.

What to Include in Your Policies

Not sure what goes into a policy? Policies can be rules, acceptable or unacceptable behaviors, limits, approval authorities (who needs to approve a decision – expense reports, discounts, etc.), consequences for non-compliance (whether it would be subject to termination), who needs to know, and how it is managed. Things that don’t belong in a policy are things like procedures. The step-by-step should be separated from the policy itself. Also, policies aren’t aspirational, so if you’re not doing something today, don’t make the policy say you’re doing something you plan to do next year. Policies are also not a place for repetitive information that collide with other policies.

Policy Writing Style

The last piece to creating good policies is understanding the writing style and the content of a policy. Policy writing style guidelines suggest that the policy title should fully characterize the content in the policy. This will allow the table of contents to be clear and concise, knowing immediately what each policy entails and who it refers to. Some examples of this would be a “Change Management Policy”, “Remote Access Policy”, “Personal Device Policy”, etc. Policies should be written in an organized way for easy navigation and should follow the natural business flow (first this, then this). When writing policies always be clear, concise, and direct, keeping it simple and making sure to not be too wordy. Another important thing to remember when crafting the language of your policies is that policies are rules, so write them as such. Use words like “will” and “must” instead of “should” to leave zero doubt. Using active voice and present tense allows you to be positive and directive. It’s important to be factual, but even more important to be accurate with your facts, so check them twice. Each department specific terms used in a policy should be properly defined and located in the glossary. You must be in the mindset of someone on the outside. If they were reading this for the first time, would they understand what the policy is referring to? Acronyms should be spelled out the first time they are mentioned in a policy and then included in the glossary.

After your policies are written, they should go through the appropriate approval process. Who has the authority to approve this kind of policy? Management? Board of Directors? Vice President? The approval process should happen with new policies, as well as with the (at a minimum) annual review of all policies, to ensure that your policies still apply and are accurate and up to date. Once policies are clearly defined and approved, they must be appropriately disseminated to all appropriate personnel, and stored somewhere everyone can have easy access to them such as the intranet.

For additional resources and advice on creating your own set of policies and procedures, contact us today.

More Resources

Quickstart to Information Security Policies for Startups

Auditor Insights: Policies and Procedures are Better Than Gold

15 Must-Have Information Security Policies

Last month, in an exclusive online interview, we asked one of our very own Information Security Auditors, Barry Williams, some frequently asked questions about PCI Data Security Standard Requirements 1 and 2. With his specialized expertise, we were able to gain some clarity on the robust information security standard.

Here are the highlights from the interview:

Q: What are some of the serious consequences you have seen or heard about regarding inaccurate PCI scoping?

The most critical thing we run across, is there is no scoping. Often times I find the network is flat and there is no segmentation of the network to separate the cardholder data environment from the rest of the network. The cardholder data environment (CDE) consists of all devices and applications that store, process, or transmit cardholder data. The scope should be determined by a good data flow diagram, showing the flow of the cardholder data. From there, you should be able to see where you can logically segment the data from the rest of the network.

Another issue that is common regarding scope, is oftentimes, the scope of a PCI assessment extends beyond the CDE. Any system connected to the CDE is also in scope. Applications, domain controllers, third-party SaaS providers, managed service providers – Anyone who manages any part of your environment should also be PCI compliant.

Q: What does “no access” mean for PCI purposes?

It means “not in-scope of the assessment”. This brings up the need for access controls procedures, having a data control policy that documents and defines those procedures, and restricts access to cardholder data by business need-to-know. The principle of least privilege with role based access, and access approval should be a clear, unambiguous policy.

Q: What are the most common gaps you see in requirement 1: install and maintain a firewall configuration to protect cardholder data?

Mostly, I see a lack of policies and procedures, mismanaged scope, lack of a detailed data flow. All of these things must be clearly and fully documented. There have to be clearly documented description of groups, roles, and responsibilities for managing network components. 1.1.5 states that all duties need to be formally defined and documented, and if they’re not, you’re not PCI compliant.

Q: My firewalls are managed by an outside IT consultant. What requirements relate to their aspect of our environment?

A lot of times you’ll get pushback from service providers, because they don’t think they’re directly involved in the storing, transmitting, or processing of cardholder data. If this company manages your firewall, they must be PCI compliant. They should provide you with an attestation stating they are compliant with the PCI standard. The new requirement for service providers says, they must acknowledge in writing that they will maintain all applicable PCI DSS requirements that pertain to them.

Q: In general, what constitutes an untrusted network?

The Internet. Also, your DMZ in your environment is also an untrusted network. Attackers are looking for your cardholder database. It should not be stored in your DMZ (web servers, DNS servers, email servers). Your DMZ should be considered an untrusted network and segmented from the rest of the network.

Q: I’m using wireless networks but only to administer my CDE. Are those networks in scope?

Yes. They are part of the “connected to”, so all wireless requirements apply. 1.1.2 – should be on network diagram. 1.2.3 – a firewall between wireless networks and the CDE. 2.2.1 – secure wireless configurations. 4.1.1 – strong encryption for authentication and transmission. 11.1 – ongoing testing for unmanaged wireless threats.

Q: What does the DSS mean by “public access”?

The DSS is trying to avoid direct contact with system components. This means, if your device has a publically accessible IP address, then anyone on the internet can communicate directly with that device.

Q: If a client has Outlook Web Access enabled for Exchange, and they use NAT on the firewall to make it available to access their account from the Internet, does this break requirements 1.3.1 and 1.3.2?

You must isolate the CDE from the Exchange server in your DMZ or you’re not compliant. If the Exchange server is officially isolated so it can’t impact the security – in any way – of your CDE, you’re okay. This is where the firewall would come into play, to segment the DMZ from the rest of the network.

Q: What does PCI mean by “unauthorized outbound traffic” in requirement 1.3.5?

According to the standard, all traffic – both inbound and outbound – must be accounted for. Requirement 1.1.6 requires documenting all services, protocols, and ports that are required for the CDE to operate correctly. Firewall configurations should only allow traffic that is specifically authorized, and this applies in both directions. In our experience, this is one of the biggest challenges with having an overly expansive scope. These controls are often so restrictive, that employees are negatively impacted when we apply the DSS to wide swaths of the business. We encourage all of our customers to take a good look at how they might be able to reduce their PCI scope and segment their network as much as possible.

Q: What methods do most companies use to obscure private/internal IP addresses?

Use of network address translation/IP masquerading is a simple method in which the source and/or destination addresses of IP packets are rewritten as they pass through a router or a firewall.

Q: Do you have any comments regarding documentation? Policies and procedures seem to be a big deal in the DSS.

The phrase “known to all affected parties” is found throughout the PCI requirements. The idea is that policies and procedures need to be documented and disseminated to all appropriate personnel. This applies to all security policies and procedures.

Q: In 2.1, what are the most commonly overlooked systems that fall into this requirement?

Sometimes systems are overlooked. This applies to all default passwords for operating systems, software that provides security services, application and system accounts, point of sale terminals, etc. Don’t only change the passwords, but also ID names.

Q: What is an industry accepted hardening standard?

A hardening standard is used to help minimize security vulnerabilities. This is done by removing all unnecessary and non-essential software programs and utilities. Good standards would include NIST, SANS, and CIS (Center for Internet Security).

Q: One of the most common challenges we encounter on our PCI assessments is weak asset management. What are the most common ways companies maintain an inventory? How does a QSA verify it’s accurate during an audit?

I always look for 4 critical components when observing a clients’ asset inventory. These are host name, description of the primary function of the device, hardware model, and software components running on the hardware. These are the most critical components to have on your inventory list.

Q: What are the common gaps when “ensuring”, as stated in 2.5?

Compliance has to be achieved and then operationalized. Policies have to be documented and disseminated to all appropriate personnel.

Q: 2.6 is critical as many companies utilize third-party cloud providers. What do companies find most challenging in meeting the requirements for shared hosting environments?

Appendix A goes into some detail here regarding additional requirements for shared hosting providers. The key point to remember here is that hosting providers must protect the environment of each of their clients, according to all the controls you find in Appendix A. The simplification of your PCI compliance can be achieved by using a shared hosting provider who already has an issued PCI Report on Compliance (RoC).

For more specific questions you’d like to ask our auditors, contact us today.

More Resources

What are the 4 Levels of PCI Compliance?

Most Common PCI Gaps

Guide to PCI Policy Requirements

As the CFPB continues to closely supervise the collections environment, it’s important to analyze and fully understand the areas of risk. One of the biggest risk to a collection agency is communication with consumers, making the monitoring of calls a very telling practice.  An effective call monitoring program is a critical component of any compliance management system, mandated by the CFPB, and is a way for organization’s to be able to monitor calls, look for areas of improvement, and to make adjustments when needed.

Let’s begin with defining what monitoring truly is, in its most elemental form. According to Wikipedia, monitoring means “to observe a situation for any changes which may occur over time, using a monitor or measuring device of some sort”. Your monitoring program is a component of your Compliance Management System that is sure to be examined by the CFPB, and according to best practices, should be occurring within multiple levels of your organization. Here are the Top 4 Critical Components of a Call Monitoring Program:

1. Structure and Oversight

The Compliance staff is a critical part to an organization who performs any kind of collection work. Selecting appropriate management and staff of that division means selecting a manager who is very knowledgeable in the collection process as well as of the regulatory laws. It also means selecting staff members who possess good compliance habits, preferably with a background in collection, and most importantly, a group of people who can be unbiased in their monitoring efforts. Before you can begin your call monitoring program, it’s important to use your risk assessment to help you determine what goals you want to accomplish by implementing a call monitoring program. Are your collectors meeting requirements by state laws? Federal laws? Contractual agreements with clients? How many calls are you going to be monitoring per collector per month? It is a best practice to monitor around 5-30 calls per agent per month. It’s crucial to be consistent across the board, and monitor the same number of calls for each collector. The calls you choose to monitor should be selected randomly, and should not all be from the same day, week, or client, and should not be tied to collector performance – maintain consistent sampling. Your policies, procedures, and work instructions for your monitoring staff should be clearly documented expectations.

2. Management of Staff

Hiring and selecting staff should be a carefully thought out process. Choosing a staff with a collection background, over choosing a staff without a collection, while not necessary is recommended. Regardless of who is selected for the QA/Compliance division, every employee should still be required to go through internal training and a mentoring process. It’s important to also create a multi-level approach to monitoring. This means don’t just get the involvement of the QA department, also have managers participate in live monitoring calls. Another valuable tool used for call monitoring is speech analytics, a tool that enables you to search calls based on criteria you set, as well as monitor to make sure collectors are following both compliance as well as client expectations.

3. Scorecard Components

Determining what your scorecard contains is not a black and white process. When developing your scorecard components, there are a number of components to take into consideration. The first being, your initial risk assessment. Utilizing a weighted score of components based on risk level and exposure is the best way to develop your scorecard components. Some things to consider when determining your risks and the level of risk are consumer complaint statistics, CFPB complaint statistics, and overall consumer lawsuits.

4. Reporting and Analytics

Recording your call monitoring results is step one to collecting your data. Reporting data can allow you to look at your results by evaluating trends by collector, client, or date range. After reviewing this information and noticing the areas in which you’re falling short of compliance and/or client requirements, it may be time to begin implementing corrective actions. In some cases, disciplinary action may be necessary. In others, updating training materials, policies, procedures, and work instructions may be the necessary course of action to ensure your collectors are following all guidelines and requirements. Lastly, don’t forget to document the results of your analysis, what you did to remediate those results, and be sure to communicate this information to the Chief Compliance Officer, compliance staff, and board of directors/management.

More Resources

Top 10 Scorecard Components for Call Monitoring

Internal Accountability: Monitoring Compliance

Monitoring Employee Records and Communications Best Practices

Data flow dynamic of payment card security

Last month, the Electronic Transactions Association (ETA), a global association which represents those in the payments space, announced a partnership with the PCI Security Standards Council (PCI SCC). This partnership brought the two together at TRANSACT 15, ETA’s annual conference, to present the industry with the most recent PCI DSS updates as well as focus the payments community on data breach prevention and payments security.

This kind of collaboration is critical when it comes to combining forces in order to conquer security and compliance. If you follow recent news headlines of the many breaches occurring at major merchants across the globe, it’s a fair assessment that we, as a whole, are failing miserably when it comes to security and compliance. The reason is simple – we are not taking responsibility for our part in PCI compliance.

The newest version of the PCI Data Security Standard (version 3.0), became fully effective on January 1, 2015. One of the major changes that in the updated version, is the clarification that payment card security is now a shared responsibility. An important thing to remember when it comes to PCI security is that the scope of the data flow is very important to the audit. Merchants have be absolving themselves of any responsibility by making broad claims that suggest that since they are using a solution that claims to be PCI compliant, they are “okay”. Meanwhile, the processors are saying it’s the merchant’s responsibility to make sure they have policies that properly govern their employees and are properly using the said solution. As you can see, responsibility has been vague, and it’s apparent that we can no longer operate that way in order to protect payment card information.

The card information flow begins with the consumer. Then the information is passed along to the merchant, then the payment processor, and finally on to the acquiring bank. Each of these parties have responsibilities along the way, and it has to be a cooperative effort by all parties involved, to ensure PCI compliance.

As clarified in January, your contractual obligations with third parties, payment processors, and vendors must now be very specific about which requirements each party is responsible for. Broad statements are no longer acceptable in your PCI audit. The recent breaches are calling for a higher level of security, and in order to accomplish this task we must all work together sharing the responsibility, and understanding the importance of applying security and compliance in every business aspect.

Are you doing your due diligence to ensure your part of PCI security? Contact us today to set up a free consultation or to talk more about your PCI security obligations.

1. Compliant ≠ Secure

One of the most troubling mindsets within an organization is “I’m compliant, ergo I’m secure.” Where compliance may be a good place to begin your “quest for security”, unless you look at your environment from a risk-based approach, and manage your environment based on the results of your risk analysis, you may be unpleasantly surprised when an outsider exploits a vulnerability found in your infrastructure. Simply checking off the boxes in order to fulfill a specific compliance requirement does not mean that you can sit back until the next audit period with the assumption your environment will remain secure and protected from any outside, malicious attacks. Maintaining security requires an ongoing analysis of business assets, and what you are doing to protect each of those assets. The best way to ensure both security and compliance is to include both in the initial business plan conversation as a two-way approach.

2. Not having a designated Compliance Officer

The role of the Chief Compliance Officer is on the rise as companies are beginning to understand the importance of designating an individual within the organization whose focus is on maintaining compliance with the constantly evolving regulatory landscape. With the sweeping realization that regulatory compliance is being more heavily enforced, many organizations are beginning to realize this may be a full-time job.

3. Thinking of independent audit as expense

The term “audit” has held a negative connotation in the business world for about as long as the word has been around. Words such as “burdensome”, “intrusive”, and “costly” may all be words we associate with an audit. It’s time for organizations to begin thinking of an independent audit not as an expense, but rather an investment. The fines that come along with non-compliance and/or data breaches will be much more costly and burdensome on your organization than being proactive about your compliance and security and planning an independent audit into your budget. Not only will you be able to validate your compliance, but having compliance audits already performed by an independent third-party auditor can also give you a competitive advantage when obtaining new business.

4. Scope mismanagement

Managing scope is critical to a successful compliance program. Understanding scope means understanding both business processes and how technology supports them. Business processes – such as the specific details as to what is asked over the phone in a call center and whether or not the entire phone call is recorded – play a significant role in identifying the technology that supports the business process. Once we’ve identified these applications and systems, it’s time to think about technical scope. Which system components store, process, or transmit the data in question? Which system components provide security services to the first group? Which system components are connected to (even if they don’t have to be) to the first group? With this information, we now know specifically where to apply all controls for a successful compliance program.

5. “Trust is a control”

In a perfect world, we would all undoubtedly trust anyone and everyone that we work with. Unfortunately, it’s important to remember that trust is not a control, and employees are humans, and humans make mistakes – intentionally or unintentionally. It’s okay to trust, but from a risk-based perspective, we must also verify. This is why monitoring, account permissions, access, and system configurations, are all among important controls that should be applied to your organization’s security posture.