Everything starts with policies. They formalize your risk & control environment and help drive action and accountability. Successful IT and security teams establish buy-in for policies and collaborate effectively with the business to enforce and manage compliance against them.
In a recent OneTrust-hosted webinar, Kevin Liu, Director of Information Security at OneTrust, and Jeremy Hendrix, Director of Information Security at Arcadia, spoke to common pitfalls of policy management for InfoSec teams and walked the audience through a series of practical steps and checkpoints that helped make their teams successful.
Additionally, Kevin and Jeremy answered follow-up questions around how they’d approach real-word scenarios around policy attestations, who should own policies, how to measure success, and more. The following is a transcription of that conversation. Liu will be noted as KL in the text, and Hendrix as JH.
Achieving compliance & building relationships with the business
Question:
As we introduce new policies or standards, the business argues we don’t “do that,” so it can’t be in the policy, and we will fail our audits, despite a strong need to move the business to adopt the change. What is the best way to address this argument?
Answer:
JH: It might help to take a step back for a moment and align on ‘why are we doing this’? The core purpose of being compliant with a policy is to manage risk across the organization. We don’t want to play ‘gotcha’ or go around slapping hands. The goal is to partner with business stakeholders to help them bake new obligations into their processes before we dictate that certain actions may be taken before we implement a control or put a new standard into place. It’s important that they know what’s coming and that we help them get there.
KL: Engage with stakeholders early and often. The result of not taking this approach will result in findings and issues, which is painful for everybody. Become that trusted advisor. Help them understand that you are not trying to restrict them from doing business, but helping ensure that they do so in a secure manner. If they need time to implement a new process or solution to be compliant, perhaps you think about risk acceptance in the interim.
Question:
Should you have aspirational policies? How do you balance the need for policies that can reasonably be met by the organization, while being able to show the bar for internal compliance has not been set too low?
Answer:
JH: If we’re creating aspirational policies, we’re shooting ourselves in the foot on achieving compliance, and creating extra work around an exception or issues management process. I have been in a situation where we were pressured by a regulator to include something in a policy that we were not compliant with at that point in time, so we time bound it. We put them in the policy, but included verbiage along the lines of “these shall be implemented within 12 months of X.”
KL: I completely agree. We should do everything we can to avoid issues, and that starts with ensuring that the statements and requirements within policies & standards are things we can achieve. If you’re aspiring to achieve something, document that outside of your policy as future goals or objectives you want to accomplish. Then work with stakeholders to establish when you can comply with these goals and objectives, and re-evaluate your policies based on your ability to comply by the effective date. This will put you in the best position to comply with these aspirational goals and future audits.
Policy attestation
Question:
Is there an acceptable level of compliance for policy attestation? For example, if 96-98% of staff have acknowledged the policy, and you’re endlessly chasing the last 2%?
Answer:
JH: The only acceptable level is 100%, and we do end up spending a lot of time chasing that last two (percent). That 100% doesn’t happen right away. We usually give 30 days and then maybe there’s a training program involved. It’s not very onerous, but it is something folks need to do. It is a thorn in our side when we have to chase these people down. But now we have these automated systems where we can deploy these nuisance emails. When you’re past due you’ll begin getting emails every day, sometimes twice a day until it’s complete.
KL: Security is too important to apply an 80/20 rule. We strive for 100% acknowledgement. We accomplish this by implementing it during week one of onboarding. New employees, including contractors, must complete the security requirements in that first week, or access will be revoked. During the annual refresher course, it is a bit more challenging. We end up chasing a little bit more for that one, but we do have processes in place to make sure the refresher courses are completed in a timely manner.
Question:
My company runs into an issue where we want to make sure policies are known/understood but attestations for all policies is unrealistic. Which policies should have attestations?
Answer:
KL: You have to understand which policies are enterprise-level and which are not. If my InfoSec is enterprise-wide, everybody must attest to it and its supporting documents. For policies that are not enterprise-wide, it’s helpful to understand people’s roles and responsibilities to provide you with a better path of which policy should be attested to by which individuals. For example, I don’t have access to make changes to our production environment or pull code sets from our code repository, so it doesn’t make sense for me to attest to our SDLC (software development life cycle) and change management policy.
JH: We attest for all our policies, but if you consider the integrated nature of policies, standards, and procedures — we really only have a few policies. Risk management, InfoSec, SDLC policies. We have a lot of standards that fall under those, however. By attesting to that InfoSec policy, they’re also attesting to those standards. So we make sure to include links to relevant standards within policies and verbiage that “by attesting to the policy, you are also attesting to the standards within.”
Policy metrics
Question:
Beyond reported incidents, what other metrics are useful in monitoring a policy program? I tend to see qualitative measures (feedback) but am interested in quantitative measures.
Answer:
KL: Metrics are important to me because they tell me what am I doing well, where I need to redeploy resources, etc. Some of my favorite metrics are from phishing campaigns, everyone does a phishing campaign, right? You send a phishing email, and the metric is how many people report it. Let’s say 80% of employees report it. Does that tell me everything I need to know about how successful the campaign was? What about the exposure time? If you send out a phishing email but the first report comes in 24 hours later, have you trained your employees to recognize a phishing email? Exposure time from when the phishing email was sent to the first report of the email is the more important metric in my opinion, because with a lower exposure time, you can delete the email from everyone’s inbox, and lower the risk of someone clicking on the phishing email which may escalate to an incident.
JH: I agree that metrics are important. Policies are a bridge from strategy to action. To have an effective strategy, you need to have an effective way to measure the action. Some of the indicators of policy effectiveness are: control effectiveness; number of issues or violations related to the policy; number of exceptions requested; and number of risks accepted against the policy.
Policy ownership
Question:
Is it ok to have policies that are co-owned? For example, existing information security policy is currently owned by IT while we stand up governance. Governance has an interest in security and data classification. So, who should own it?
Answer:
KL: It really depends on how your organization is set up. Is there conflict of interest? If IT is owning a policy that they also must comply with, I’d question if there is any risk with that kind of ownership. Should it be separated where you have a dedicated team that’s reviewing or updating it? If you’re too small of a shop, you have to make sure it’s right-sized so you’re not creating too much of a resource constraint. You’ll need to establish roles and responsibilities on who’s updating or authoring the policy. Have a review & approval process established with potential conflicts of interest in mind.
JH: I don’t think there’s any specific guidance that says you can’t, but I think best practice would be to have a singular owner. If we need to, bring IT folks in as collaborators, and if there’s a need to expand out, then you can involve committees. That way you can get more ownership across the organization.
The path to creating an effective policy management process is not a smooth or straight one. However, it can be paved by teamwork that includes clear ownership and stakeholder buy-in. To find out more about the process and building blocks needed to succeed, watch the webinar here.
To learn more about OneTrust GRC & Security Assurance and request a demo, click here.
