Services
Services
SOC & Attestations
SOC & Attestations
Payment Card Assessments
Payment Card Assessments
ISO Certifications
ISO Certifications
Privacy Assessments
Privacy Assessments
Federal Assessments
Federal Assessments
Healthcare Assessments
Healthcare Assessments
Penetration Testing
Penetration Testing
Cybersecurity Assessments
Cybersecurity Assessments
Crypto and Digital Trust
Crypto and Digital Trust
Schellman Training
Schellman Training
Industry Solutions
Industry Solutions
Cloud Computing & Data Centers
Cloud Computing & Data Centers
Financial Services & Fintech
Financial Services & Fintech
Healthcare
Healthcare
Payment Card Processing
Payment Card Processing
US Government
US Government
Learning Center
Learning Center
Articles
Articles
Whitepapers
Whitepapers
Case Studies
Case Studies
Events & Live Webinars
Events & Live Webinars
On-Demand Webinars
On-Demand Webinars
About Us
About Us
Leadership Team
Leadership Team
Careers
Careers
Corporate Social Responsibility
Corporate Social Responsibility

How to get G, R & C Singing From the Same Hymn Book

Deciphering the conflicted angst of GRC

There is no one-size-fits-all for GRC so companies need to take a hard look at their regulatory requirements, along with their corporate culture and business models, to build a viable GRC program. Indeed, GRC is still a work in progress, even though each component has been a business imperative for years. Alan Earls reports.

When governance, risk and compliance were formally defined in 2007 in a scholarly report by Scott Mitchell as an “integrated collection of capabilities,” it meant that each of those areas of corporate responsibility got a boost in visibility.

However, while their profiles have increased, governance, risk, and compliance are by no means identical in their needs, methods, or goals, a fact that can produce inevitable, if too often unexpressed, conflict. And certainly these principles are hardly in sync for every company.

“There are two types of organizations when it comes to GRC: those that are struggling to master GRC and those that lie about it,” says Pablo G. Molina, CISO at Drexel University. GRC is ongoing and challenging, “bringing about conflicts between the mission of the organization and the constraints imposed by regulators and bad actors,” he says. What they are not is easy.

Diagnosing the GRC malaise

The demand for time and effort from CISOs is high, while the supply is low, notes Molina. Whereas many GRC pundits engage in intellectual, protracted discussions about issues, “CISOs look for practical, efficient, and effective solutions, then, they move on to the next challenge,” Molina says. GRC, however, “is not always about moving on but about moving forward [and] making progress,” he adds.

In fact, there are some fundamental problems that make GRC balance a real challenge and make moving forward difficult. One problem, according to Michael Schenck, director of security services at ManhattanTechSupport.com, is that most companies have little genuine concern for security and will therefore only do the absolute minimum needed for compliance. And that makes for a big disconnect in motivations and in standing with management. “The most effective driver for companies to spend on security remains post-incident,” he adds. Compliance, with its comparatively clear requirements — as opposed to the open-ended, never-enough world of security has become the squeaky wheel that gets the grease.

“Boardrooms all over the world are now tackling risk and compliance in a more direct way than ever before,” says Travis Greene, director of IT operations product marketing at Micro Focus, a Newbury, Berkshire, U.K.-based enterprise application integration and management software and consulting company. He says that means CISOs knowing where their data resides — a major compliance concern — is just as important as how to stop cyber threats.

Expanding on a similar point, Nathan Wenzler, senior director of cybersecurity at Moss Adams, a Seattle-based accounting, consulting, and wealth management firm, says as networks and applications become more complex, the differences between traditional risk mitigation strategies and regulatory compliance requirements have grown. “Compliance is strict, attempting to standardize and normalize security functions so that they are consistent, easy to measure, and verifiable. But, as the complexity of systems increases, it becomes harder to standardize all of the functions and controls to a single set of requirements,” he says.

Attorney Adam Cohen, a partner at Redgrave LLP, notes, “The disconnect for GRC things is that the security organization may have put in place something they believe is secure and that manages risk generally in a way that is appropriate for that environment.”

However, they might not understand what the legal standards are and they might really need to do things that they do not think are necessary from a security point of view but are required from a legal point of view. “You can have perfectly legal compliance; you can’t have perfect security, and everyone knows that,” he adds.

The disparities between the two realms leave cybersecurity staff in particular with a sense of trying to achieve the impossible — and that compliance-driven behavior can cause problems.

“I like to advise [security professionals] that compliance doesn’t always bring you compliance, but best practices always brings you compliance..."

“I like to advise [security professionals] that compliance doesn’t always bring you compliance, but best practices always brings you compliance,” says Gregory Touhill, a former CISO for the Office of Management and Budget and now an adjunct faculty member at Carnegie Mellon University. Why is this? Regulators and compliance documentation often lag behind best practices and advances in technology, Touhill says. “Criminal hackers like to use state-of-the-art capabilities and you need state-of-the-art practices, too.”

Regulatory drivers

Of course, the whole GRC conversation constantly must be adjusted to shifting regulatory requirements. For example, “We’re seeing more and more regulations around the world, with different countries that either consider [a law similar to] GDPR or are inspired by it,” says Ilias Chantzos, senior director of government affairs for Europe, Middle East, Africa, Asia Pacific, and Japan at Symantec. In many ways, this is not surprising. If everyone agrees that data is valuable, then it is only normal that there be rules on how to access it and what you can and cannot do with it, he says.

The European Union’s General Data Protection Regulation (GDPR) is one of those cases where governance, risk, and compliance are not necessarily at odds with each other, says Chantzos. As organizations evolve and change over time, compliance posture will change and governance models need to be flexible enough to adjust and incorporate new realities such as a new acquisition, line of business, use case, or the introduction of a new technology, he says.

Likewise, risk will continue to fluctuate depending on the business model, the data processed, the maturity of an organization, the risk appetite of its leadership, and the attitude of local regulators.

Chantzos says enterprises ultimately must take a holistic approach, demonstrating to the satisfaction of regulators and their customers that they have the proper steps in place to handle data, leading to better governance, more transparency and improved decision making.

Indeed, several regulations have been moving toward a risk management-based approach, though many still do not address any risk other than failure to comply and getting caught, says Schenck. For example, he notes, the National Institute of Standards and Technology (NIST) is now advising using passphrases that do not have specific complexity requirement nor do they have to be changed on a scheduled basis.

Walk the walk but also talk the talk

"The biggest and least technical strain or stress in the GRC balancing act is communication..."

“The biggest and least technical strain or stress in the GRC balancing act is communication, particularly in the enterprise-level space,” says Bryan Harper, a senior associate and manager of Tampa-based Schellman & Company, LLC, a global independent security and privacy compliance assessor. There is simply too little discussion among stakeholders. Typically, this occurs because “our auditors says we must…” or “the consultant advised us to address X requirement” in a particular framework, he says. Harper works from the Atlanta office.

Harper says instead of simply taking that alleged requirement and bulldozing ahead, sensible compliance personnel should:

  • Understand the “why” behind the competing requirements or new requirement
  • Understand the entire breadth of the compliance schema the company is attempting to address (essentially the other “whys”)
  • Understand the needs and practicalities of the business or business unit(s) that might be impacted
  • Balance those things into a common-sense solution that works for all stakeholders.

“This is in stark contrast to compliance-based requirements in the past with 12-character passwords that mix upper- and lower-case letters with numbers or symbols and that had to be changed every 90 days,” says Schenck. Many compliance requirements do not allow for this risk-based change, namely the risk of people using bad passwords or writing them down because they are too long to be words, too short to be passphrases.

The key, says Cohen, is that many, but not all, regulatory requirements have some kind of reasonableness standard. So, while there might not be a settled standard of “listed” requirements, “there a pretty clear list of unreasonable items.” For example, if you’re missing certain basic security components, you will not be legally compliant or will likely be viewed as out of compliance.

Read full article at SE Library >>

About BRYAN HARPER

Bryan Harper is a Manager with Schellman. Prior to joining Schellman in 2017, Bryan worked as a Senior IT Auditor, specializing in SOC examinations. Bryan also worked as a staff accountant in a public accounting firm performing financial audits, consulting, and out-­sourced internal audit engagements for clients in the banking, insurance, and healthcare industries. Bryan is now focused primarily on SOC examinations for organizations across various industries. At Schellman, Bryan is involved with technical training development specific to auditing cloud services and supports Schellman's cybersecurity task force, which is responsible for monitoring developments in and responding to cybersecurity regulations and related cybersecurity compliance frameworks.