Paul Proctor
VP Distinguished Analyst
10 years at Gartner
28 years IT Industry
Paul Proctor is a vice president, distinguished analyst, and the chief of research for security and risk management. He helps organizations build mature risk and security programs that are aligned with business need. Read Full Bio
by Paul Proctor | May 15, 2013 | 1 Comment
IT-GRC is essentially enterprise GRC functions (workflow, data repository, regulatory mapping, etc) focused on IT specific needs. The only reason we have IT-GRC is because, traditionally, the original GRC vendors were focused on addressing SOX and other global financial integrity regulations and were terrible at IT requirements. That gap is closing however.
For the last two years, IT-GRC has started to bifurcate into IT-related GRC functions and security operations functions. These market changes have caused us to reset Gartner’s use of the term IT GRC to provide useful guidance to our clients in selecting appropriate technologies for their requirements.
GRC is the most worthless term in the vendor lexicon. Vendors use it to describe whatever they are selling and Gartner clients use it to describe whatever problem they have. See my previous post Why I Hate the Term GRC.
In 2013, there is little evidence that security technology data is being used in any material or comprehensive manner to directly support senior IT and business leadership in decision making. However, there is an important evolution in the prioritization and remediation of vulnerability and security configuration management data using business context that is changing vulnerability management and other security operations use cases. This evolution will be covered separately from IT GRC technologies.
Gartner experience on client and reference calls has indicated that IT GRC needs fall roughly in two areas. The first supports oversight and governance functions that typically bridge IT information to support IT and business leadership for reporting and decision making. This is present in use cases such as vendor risk management, policy management, integrated risk reporting and risk assessment. The second supports information security operations requirements through the centralization of security technology data. This is present in use cases such as vulnerability management, continuous monitoring and the management of technology-centric compliance requirements such as Payment Card Industry Data Security Standard (PCI DSS).
Consider a metaphor where a horizontal line is used to separate IT from non-IT business needs (see figure below). The first area can be described as "above the line," and the second area can be described as "below the line"
Using patch management as an example, the operations functions that monitor patch states, prioritize and guide remediation are all within the first line of defense. They are considered below the line and not within the definition of IT GRC. The governance functions that use patch information to rate business units on patching effectiveness to guide risk-related decision making are part of the second line of defense. They are above the line and considered to be a part of core IT GRC activity.
IT GRC technologies and providers for above-the-line use cases will be published in the latest MarketScope for IT GRC. Below-the-line requirements will be addressed, in part, as an extension of vulnerability management. There is no hard definition for below-the-line use cases that have been excluded from IT GRC because this is an evolving set of solutions that include traditional IT GRC vendors and vulnerability management vendors.
Our new definition of IT-GRC
IT GRC technologies are used primarily to bridge IT-related data in support of senior IT and non-IT decision making. This is composed of functions for mapping controls into control objectives, survey capabilities, workflow to support non-IT decision making, and non-IT executive reporting.
The use cases for security operations will no longer be referenced as IT GRC at Gartner and will be considered an extension of vulnerability management research for the benefit of IT operations. This is composed of functions for the import of technical data from third-party products, workflow to support prioritization and IT remediation activities, and an IT asset database supporting IT decision making.
IT GRC is composed of functions to support non-IT decision making and non-IT executive reporting:
- Controls and policy mapping.
- Survey capabilities.
- GRC asset repository.
- Workflow.
- IT risk evaluation and dashboards.
The functions supporting data import from third-party security tools, such as vulnerability assessment and security configuration management, remain a part of IT GRC. However, these functions are primarily used in support of the below-the-line security technology use cases.
These changes seem to have everyone in a tizzy. But here’s the bottom line: Security operations is security operations. Gartner is not going to call that IT GRC. So there.
Follow me on Twitter (@peproctor)
Category: Uncategorized Tags:
by Paul Proctor | May 13, 2013 | 10 Comments
GRC is the most worthless term in the vendor lexicon. Vendors use it to describe whatever they are selling and Gartner clients use it to describe whatever problem they have. For seven years I have battled this monolithic term and I fear I’m losing the battle. The alternative is to try to bring some clarity to its usage by defining some boundaries.
Here is our published GRC definition, which I like:
GRC is neither a project nor a technology, but a corporate objective for improving governance through more-effective compliance and a better understanding of the impact of risk on business performance. Governance, risk management and compliance have many valid definitions. The following definitions illustrate the relationship of the three terms and serve for Gartner’s GRC research:
- Governance — The process by which policy is set and decision making is executed.
- Risk Management —The process for preventing an unacceptable level of uncertainty in business objectives with a balance of avoidance through reconsideration of objectives, mitigation through the application of controls, transfer through insurance and acceptance through governance mechanisms. It is also the process to ensure that important business processes and behaviors remain within the tolerances associated with policies and decisions set through the governance process.
- Compliance — The process of adherence to policies and decisions. Policies can be derived from internal directives, procedures and requirements, or external laws, regulations, standards and agreements.
When it comes to GRC technologies we have to define some boundaries or essentially GRC is everything and everything is GRC. Well who does that help?
- It’s important to know which projects, workflows, and processes are in scope before starting a tool acquisition process.
- GRC tools are good for automating EXISTING, good processes
- Buying a tool to solve your GRC problems is putting the cart before the horse. For example, if you don’t have risk assessment, buying a GRC tool is not going to give it to you.
IT GRC is a particularly complicated issue so we have recently evolved our definition to help Gartner clients match their need to product capabilities. My next blog post will address this issue in a couple of days.
Follow me on Twitter (@peproctor)
Category: Uncategorized Tags:
by Paul Proctor | May 6, 2013 | 2 Comments
I have some good news and some bad news. The good news is that demand for security people is at an all-time high, as are salaries. The bad news is that this “job seeker’s” market is creating some bad behaviors and numerous problems for organizations who have finally seen the light over proactively addressing security.
A recent article in Computerworld discussed a study of cybersecurity job postings done by Burning Glass Technologies:
“In 2012, there were more than 67,400 separate postings for cybersecurity-related jobs in a range of industries, including defense, financial services, retail, healthcare and professional services. The 2012 total is 73% higher than the number of security jobs posted in 2007, Burning Glass said. “
“According to Burning Glass, cybersecurity jobs on average offer a premium of about $12,000 over the the average for all computer jobs — the advertised salary for cybersecurity jobs in 2012 was $100,733 versus $89,205 for all computer jobs.”
This demand makes sense given the increase in security program maturity that Gartner has been watching for 10 years. More companies waking up to the fact that security requires investment and experienced people.
Hold up on the celebration though, here’s what I’ve learned from the companies I speak to every day.
- The hiring managers are having problems making the business case for the higher salaries
- The candidates tend to be very young, with minimal experience, but demanding very high salaries.
- The candidates tend to know technology, but not program management resulting in continued focus on technology as the answer to solve security issues.
- There is a class of security expert that is now job hopping every couple of years leaving the organization in the lurch.
The bottom line is that it is very hard to develop a mature program when you can’t find experienced resources that know program management AND security technology.
My advice to clients
- Consider hiring from within, someone who knows your company and IT, and a desire to learn the security skills. This should not be a hard sell to potential candidates given the skyrocketing demand.
- Prioritize program management experience over technology skills if you’re looking for a security manager or CISO.
- Work with HR on retention to address the risk of job hopping.
- Keep up on the latest salary surveys to make the business case. You can’t hire a CISO for $80K.
What is your experience?
Follow me on Twitter (@peproctor)
Category: Uncategorized Tags:
by Paul Proctor | April 26, 2013 | Submit a Comment
On 25 April 2013 the Chicago Board Options Exchange was out for half a day preventing trading on two very important stock indexes. IT risk is not just a technical problem, handled by technical people, buried in IT. Many executives still have not gotten the message.
On 1 August 2012, test application code was run in a live production environment at the trading firm Knight Capital in New York. In 45 minutes, $440 million was lost and the firm almost had to close its doors. These incidents demonstrate that IT risk has business consequences.
As we note in our report: IT Risk Has Real Business Consequences; Lessons From Knight Capital
Key Challenges
· Non-IT executives do not generally understand the impact of IT risk on business outcomes.
· IT organizations do not always apply appropriate controls to address reasonably anticipated IT risks.
· Good risk management practices are not sufficiently formalized in many organizations, reducing their effectiveness.
Recommendations
· Develop a business case and appropriate communications plan to help non-IT executives understand the business impact of IT risk.
· Develop appropriate controls to address reasonably anticipated IT risks.
· Integrate risk management and corporate performance in a formal IT risk program to appropriately manage IT risks.
Using the incidents at Knight Capital and the CBOE as examples, there are several lessons to be learned that apply universally to all organizations, especially those with heavy technology dependence.
· Do not run test code on production systems.
· When IT and business process failures, occur you have an opportunity to strengthen controls and institutionalize good practices.
· Preventative controls can limit damage.
· Compensating controls can be powerful protection if applied jointly and severally.
· Process controls must work in concert with technical controls.
· Application development should embed controls to protect against reasonably anticipated risk.
· In highly complicated and complex environments, risk management should be appropriately aggressive, comprehensive and applicable.
Good risk management should influence better business decision making. Organizations must separate IT operational risks that should be kept within IT from IT risks that have genuine business impact. This can be done by identifying business outcomes, related business processes and IT dependencies.
Creating risk-adjusted value chains will embed risk thinking in management decisions, and surface IT risks like those suffered by Knight Capital (see "Improve Business Decision Making With Risk-Adjusted Value Management: Creating Risk-Adjusted Key Performance Indicators").
Formalizing a risk program with a charter, a process catalog, a risk assessment methodology and a risk register, and linking these aspects to the performance potential of the firm, will provide a foundation to promote the benefit of risk management to the non-IT parts of the business (see "Six Required Elements of Effective Risk Management").
You need to be a Gartner client to read the Gartner reports.
Follow me on Twitter (@peproctor)
Category: Uncategorized Tags:
by Paul Proctor | April 8, 2013 | 1 Comment
One of my favorite scenes in The Big Lebowski is when he runs afoul of the Sheriff in Malibu who tells him very clearly, “Stay out of Malibu Lebowski!”. To be clear, it is management’s role to assess and address risk appropriately and audit’s role to provide assurance. It is not audit’s role to step in and fill the gap if 
management is doing a poor job with risk management. In a phrase, “Stay out of Risk Management, Audit!”
There has been a drumbeat for the last 10 years for internal audit professionals to improve their risk management skills and get “appropriately” integrated with risk management activities. This seems admirable on the surface, but the dark underbelly is that they are increasingly acting like risk managers.
To their credit the Institute of Internal Auditors (IIA) gets it, but some of their language can be twisted by the opportunists. In the 2004 position statement from the Institute of Internal Auditors: The Role of Internal Audit in Enterprise-Wide Risk Management you can see how words like “Developing risk management strategy,” “Coordinating ERM activities,” and “Maintaining and developing the ERM framework” make what they call “legitimate” auditor activities look a lot like risk management responsibilities.
And their internal audit standard 2120 also contains language that can be misconstrued by gung ho auditors looking to increase their influence.
Before I get a bunch of cards and letters saying that I don’t understand the official position, I do. My problem is with my own experience with Gartner clients (greater than 60,000 organizations globally):
- Audit superseding legitimate business decisions to accept a risk by writing a finding anyway.
- Too many organizations have audit and IT Risk organizations reporting into the same executive, or worse, their risk and security people reporting into audit! Talk about conflict of interest.
- Organizations that rely on internal audit to identify their risks, and put their focus on addressing audit findings as the primary mechanism to protect the organization.
The issue is punctuated by a recent PWC 2013 State of Internal Audit Profession Study which laments “internal audit needs to step outside of its traditional comfort zone, and contribute to the organisation in a more meaningful way, or fall into obsolescence as other risk-management functions outpace them.”
It goes on to support gems such as this:
- Problem-solving internal audit functions are leveraging expertise and technology-enabled analysis to identify root causes to help management understand and solve specific issues. They also are more integrated with other risk management functions in the organization to ensure risks are well managed.
- Companies must collectively confirm the organization’s risk profile and internal audit’s contribution to helping to monitor it.
- Ask how key business risks are addressed by internal audit in the context of the organization’s aggregate risk coverage.
In a recent WSJ blog on the PWC survey
Panelists discussing the survey in a webcast on March 26 noted that the demands on internal audit had changed, and some identified enterprise risk management as a challenge to which the internal audit profession had to rise . (Enterprise risk management takes a holistic view of all risks that can affect the value of the firm.) It seems from the survey that there’s a long way to go. PwC warns that there is risk of the internal audit function “losing relevance as other risk functions become more vital contributors to the organization’s risk management.”
Aarg. To put it succinctly again in the spirit of Lebowski’s Sheriff of Malibu: “Keep your ugly, goldbricking asses, out of my beach community.”
Category: Uncategorized Tags:
by Paul Proctor | April 1, 2013 | 2 Comments
Compliance is no longer the driver for IT risk and security. Compliance is just one of many risk domains to be addressed in a mature risk management program and approach.
Organizations must develop a mature risk management program and approach to effectively manage IT risk and security through well designed, implemented and executed controls. The goal of this program should be to balance the needs to protect the organization against the needs to run the business. Compliance should be treated as a domain of risk within this program and should not be allowed to drive decision making. Compliance is an outcome of a well-run risk management program.
Responding to regulatory mandates can result in a focus on addressing the mandate, and not the protection of the organization. Compliance has become a panacea for many organizations to describe whatever actions they take to address risk and security, because they have a regulatory requirement to do so. In many organizations, the security team reports into the compliance function and this is counterproductive.
Stop Trying to Be Compliant, Because That Isn’t What the Laws Require Anyway
Compliance mandates have been in transition for more than a decade to become risk-based but organizations have not kept pace. They have all transitioned away from a list of controls you must implement (classic compliance approach) to a requirement to do a risk assessment and the implementation of appropriate controls based on level of risk.
HIPAA for example, is not a list of controls that should be implemented. It is a list of risk domains with the requirement to do a risk assessment and determine which controls are reasonable and appropriate to address reasonably anticipated risks. Any controls deemed reasonable and appropriate are then required by law. In a 2012 series of spot check audits for health care organizations in the United States, most failed, not because of a lack of controls, but for the lack of a recent risk assessment to support their control implementation choices.
This approach gives organizations the flexibility to do what is necessary for their unique situation and create a program of controls that actually help the organizations succeed. Too often organizations still treat compliance activities as a check-box exercise with little regard for the related risks they are intended to address.
Stop Chasing Your Tail On Specific Regulations, Regulatory Distraction Must End
Most organizations are so buried in risk and security compliance requirements that they can’t keep up with all of them. In the United States, an organization must address a patchwork of state regulations for the protection of personally identifiable information (PII) and breach notification, industry specific regulation (HIPAA, NERC-CIP, GLBA, CFR 21 Part 11, etc), and emerging federal requirements. Global enterprises have a patchwork of privacy and security requirements that vary greatly from country to country. All of this creates a level of regulatory distraction that makes success almost impossible.
Gartner recommends organizations create a formal and defensible program of controls based on the specific situation and risks unique to each organization. The rules and laws should then be mapped into the controls that have been proactively selected and a defensible case made that the laws are being appropriately addressed. As stated earlier, this risk-based approach is what most of the laws require in any case. Real gaps can be identified and addressed.
Treated in this manner, compliance becomes just another silo of risk that is addressed as an exercise in mapping and defensibility.
Stop Being a Rule Follower and Become a Risk Leader
Rule followers focus on compliance as a way to avoid negative outcomes and risk leaders focus on ways to adapt to ever-changing risks and achieve positive outcomes. Followers are buried in regulatory distraction that impedes their ability to innovate, perform, optimize and adapt their programs. Followers are busy covering their butts.
Leaders are able to map risk and security dependencies into desired business outcomes and report these risks into the appropriate decision makers. For example, a modern risk and security program can support mergers and acquisitions through proactive due diligence that guides actual integration decisions by non-IT decision makers. That’s influencing the business!
Compliance no longer the driver, Adapt or die
Organizations must inculcate an appropriate level of risk awareness and ownership by those responsible for achieving the desired business outcomes in support of the company’s strategic goals.
Accountability: How do we reinforce the ownership of risk and control within the enterprise?
Action: How can we ensure that employees act in the best interests of the company and within established risk tolerances?
Achievement: What risk metrics are required, and how are they linked to performance metrics to ensure the desired business outcome?
Category: Uncategorized Tags:
by Paul Proctor | February 24, 2013 | Comments Off
I have the best job in the world. I get to speak to the best and the brightest IT risk and security officers every day to learn what works and what doesn’t. … I also get to speak to the other end of the spectrum. Here are a few doozies for the record books.
A textbook dashboard with no relevance.
I help our clients build effective dashboards with risk and security metrics tied to corporate performance goals. However, there’s always a starting point (I review their current dashboard) and this is a common failure. Many of them are works of art loaded with eye candy graphics and very important sounding metrics like “Attack surface increase quarter by quarter”. These are what I refer to as text-book perfect dashboards because they appear 
constructed by very highly paid consultants following a formula.
This is where it comes off the rails. I ask the author to tell me what decisions any of these metrics influence for the intended audience (IT execs, BoD, etc.). This is usually followed by a long silence and “… I see what you mean.”
You can avoid this failure by understanding what decisions your intended audience makes every day and relating their decisions to dependencies on IT and operational risks.
Reporting raw vulnerability numbers
This is my all-time favorite CISO fail. The CISO chose to report raw vulnerability numbers to their board of directors. They did this in the name of transparency and, in that spirit, chose not to turn off any of the scan categories. You can’t make this stuff up.
This small company discovered they had more than 70,000 vulnerabilities and the board’s reaction was to say “fix all of those and make it zero”. Because they had not tuned the scan it was showing them vulnerabilities for applications they did not even have! Net result, it was actually impossible to make the number zero… and they had to explain this their board. I swear, you can’t make this stuff up.
Please avoid this failure by abstracting all the technology out of your reports to the board. They don’t understand it and when you try to explain it, the best possible outcome is that they fall asleep. The worst possible outcome is they will misinterpret it and make your life a nightmare.
Attacking the infrastructure without warning to prove “it is weak”
This is sadly more common than it should be. Gung ho security officers who have bad working relationships with their counterparts in IT operations like to “show them a thing or two” when push comes to shove. In some extreme cases of this I’ve heard of critical business services going down during business hours.
You can avoid this by maintaining a good working relationship with IT operations and never, never do anything that puts business operations at risk. The fact that I’m even writing this just makes me sad…
A CEO who wants a “forceful” CISO to aggressively control people as a way of improving security
This last one isn’t a CISO failure, it’s a CEO failure. A large multi-national corporation had woken up to the fact that security was important. The trigger of course was a breach notification and a fine. When interviewing CISO candidates he explicitly said that he wanted someone to “kick butt and take names.” The emphasis was on the fact 
that security was going to be a mandate pressed down from the top.
For insight into the failure here, read numbers 2 and 3 on this list. Management by fiat does not work. Support from the top should not mean the ability to walk around and tell people what they can and can’t do. We know this now after 10 years of “Dr. No” and the negative impacts on security.
To avoid this failure embrace the modern risk-based approach to security that balances the need to protect the organization with the needs to run the business.
Do you have any failures to share? What have you learned?
Twitter: @peproctor
Category: Uncategorized Tags:
by Paul Proctor | February 8, 2013 | Comments Off
CISO’s biggest challenge by far is getting executive management to appreciate (and fund) what they do. This scene plays itself out time and time again across the globe in every industry:
CISO walks in to the CFO’s office and says “I need $1M to protect the company.” CFO says “How much did you spend last year?”. CISO: “Nothing.” CFO: “…and what happened?” CISO: “Nothing.” CFO: “Ok, go do that again.”
The good news is that you can beat this by changing the narrative. Stop asking for money and start asking for decisions. We all live in a continuum of risk wherein we choose to spend less money and experience more risk OR spend more money and experience less risk. Explain this to the decision makers and ask them to commit to their choice as to where they want to live on this continuum.
Choosing to save some money and experience more risk is a legitimate business decision. The failure is allowing executives to live there without making a conscious choice. CISOs are their own worst enemy when they position themselves as defenders of the organization because it lets the executives skate on accountability.
Saying the risk is owned by the business is not just a platitude. A CISO must have the ability to translate this into reality.
I’ve arranged to have this Gartner research report made available until March 5, 2013. Non Gartner clients have to register to get it, but I think most will find it worthwhile.
Gartner Report: Eight Practical Tips to Link Risk and Security to Corporate Performance
Non-Gartner clients click here to get report
Gartner clients click here to get report
Twitter @peproctor
Category: Uncategorized Tags:
by Paul Proctor | January 28, 2013 | 1 Comment
After more than 10 years of evolution it’s time to hit the reset button on security and risk management. Your approach, your career, and your responsibilities all need hard change. There are many truths we have all known for years but culture changes slowly.
2013 is the tipping point where risk and security professionals have to kick evolution into high gear and engage their world differently.
- We are no longer the group responsible for protecting the organization from cyber threats, we are the group that helps stakeholders balance the need to protect the business from the needs to operate the business.
- We no longer focus exclusively on the technology of security, we engage all the controls at our disposal including behavior change, process, and technology controls.
- We no longer seek to prevent every possible threat, we assess and prioritize risks to support conscious choices about what will and will not be done to address threats.
- We are no longer buried deep in IT, we understand the impact IT risk and security has on business outcomes.
- We no longer rely on smart people who know what to do, we formalize are programs with repeatable, survivable, and measureable processes.
The risk and security revolution is over and WE won! Now it’s time to reset how you work.
- Stop using older control technologies such as firewalls and upgrade to next generation firewalls
- Stop treating your DLP like a data firewall and see how it can be a powerful force to change user behavior.
- Stop confusing non-IT stakeholders with IT jargon and see how to communicate effectively to executives and boards of directors.
- Stop reporting failed operational metrics and engage in leading risk indicators to influence business decision making.
Listen to this replay of a webinar on running, growing, and transforming your risk and security program. It’s open to all. If you aren’t a Gartner client just click sign in to register.
Category: Uncategorized Tags:
by Paul Proctor | January 21, 2013 | Comments Off
My good friend Gene Kim has published a new book called “The Phoenix Project. A Novel About IT, DevOps, and Helping Your Business Win” with co-authors Kevin Behr and George Spafford (a fellow Gartner Analyst).
The book is a short novel about
a fictional company that is much more dependent on IT than the executives understand. When IT starts to go south, so does their business. It’s the story of the different players across IT and the C suite as they work to right the ship and create resilience across the enterprise.
The real triumph in this book is that it can be read and understood by both IT and non-IT executives. I feel very strongly that these audiences don’t understand each other and anything that bridges the gap is welcome. The characters are drawn like real people like the ones you work with and you will recognize them.
This book is a must read for IT risk and security professionals. You can get a bigger win if you can get your non-IT executives to read it. The higher up in the organization, the better. Check to see if your executives have a business book club or web page. I’ll bet they don’t have many IT books in there.
Category: Uncategorized Tags:
