The Way You Manage Risk Could Be Putting Your Organization at Risk

Gone are the days of adequately protecting your organization by obtaining a SOC2 type 2 auditor’s report or an ISO 27001 certificate. Many experienced practitioners always knew that such a milestone was never a proper measure of an organization’s security posture or maturity. And recently, it seems, the rest of the world has caught on.

Not only are regulatory and governance pressures growing, the security threat landscape is also expanding. Attackers have become plentiful and sophisticated, the number of attack vectors is increasing, the attack surface for organizations is growing and the complexity of our digital footprint has expanded exponentially. To top things off, the shortage of qualified and available personnel to fill security roles, including GRC roles, has skyrocketed.

In short, there’s an abundance of challenges for GRC leaders in today’s organizations. But surprisingly I hear very little conversation around the most fruitful ways of running a modern GRC or risk management program. There may not be a single right answer since every organization is unique. However, there are ways to modernize your processes.

To get to the bottom of this, let’s explore some of these questions:

• How are you managing risk and your GRC program today?
• With many organizations accelerating the way they build and ship products, why is it that the technology has changed so drastically but GRC program management has largely stayed the same?
• Is there a more efficient and fulfilling way to manage today’s modern GRC program?

Exploring Governance, Risk and Compliance (GRC)

My personal experience is firmly rooted in the Federal space having spent much of my career running compliance programs heavily scoped to FISMA – whether it be NISPOM, FedRAMP or some other variation. I also have extensive experience running programs at SaaS companies including private sector Information Security Frameworks like the AICPA Trust Service Criteria for SOC2 and ISO 27001.

Here’s my take on GRC:

Governance relates to statutory or contractual obligations on an organization in terms of security, risk and privacy objectives. Non-Compliance can result in severe penalties, in some cases including criminal liability. When managing GRC programs supporting National Defense practitioners can even be subject to prosecution from mishandling of National Defense Information.

Risk relates to managing risk within an organization – specifically scoped to security and privacy requirements, but this often ties in (or should tie in) heavily with Enterprise Risk Management.

Compliance relates to an organization putting in place security and privacy controls to meet governance requirements and reduce risk. Internal and third-party external audits are a huge part of the compliance portion of a modern GRC program.

Top Challenges With GRC and Risk Management

As alluded to earlier, the sheer number of regulatory and contractual requirements faced by a modern organization are breathtaking, and not in a pleasant way. There is a plethora of regional and industry-specific requirements being propagated at break-neck speeds.

Likewise the number of organizations pushing “flow-down” requirements contractually is challenging to keep up with. There are very few organizations, if any, in this modern world complying with just one piece of governance. Even in the case of meeting requirements for an individual security compliance framework, there are massive cross-references and supporting requirements that an organization must account for.

Adding to that challenge, personnel shortages and burnout are at a record high. Industry research points to the fact that this gap will continue to grow in the near term, and will remain a problem for quite some time. Due to the complexity of the regulatory space, it is extremely hard to have a true “entry-level” GRC position. It is not uncommon to see a job listed as entry level yet have requirements that are clearly not such.

Increasing demands from within the organization are also growing. We see more and more that GRC is becoming a more important priority for boards of organizations, specifically in risk management. The message is loud and clear in today’s environment – organizations are expected to reasonably protect the security and privacy of the data they are entrusted with.

We are seeing severe financial impacts and even criminal prosecutions for lack of oversight and diligence in these areas. However, all of this attention is thankfully getting security embedded into engineering and business processes earlier and more frequently. The down-side of this, however, is that organizations are still hesitant to “staff-up” to support this growing need.

Security, especially GRC, has traditionally been seen as a cash drain and not a value driver. To top things off, the technologies and methodologies being employed today are changing at breakneck speed. Don’t get me wrong, DevOps is AWESOME and has understandably changed the world. But many GRC practitioners are still trying to get up to speed on the latest and greatest technologies that today’s engineering teams are working with. Because the shortage of personnel and mounting demands rarely leave us with much time to continue our growth and development, we get caught in a vicious cycle.

Running a GRC or Risk Management Program

At its bare minimum, running a GRC program requires the team to first identify and continuously track which regulatory and contractual obligations the organization is required to adhere to. In fact, many regulatory frameworks require you to monitor and assess your requirements regularly. This gets really tricky at organizations that make lots of “one-off” exceptions for “highly qualified” clients or customers. But without this first step, you are definitely not compliant.

After requirements are identified the hard work can begin, which starts with clearly understanding the environment of the organization. What people, processes and technology are in place at the organization? What is the culture of the organization? What is the risk appetite of the organization? If you can’t answer these questions, then you can’t properly assess compliance. In this phase we are trying to piece together several key “pictures” including:

Once clear “pictures” are obtained, the GRC professional can set onto the path of designing, implementing and testing security and privacy controls. These activities historically have been run using spreadsheets, rich text documents and shared network (or cloud) storage.

Traditionally there are lots of email messages, direct messaging and meetings. The result is duplicative manual processes, burnout and frustration for all parties involved. In the traditional way of running things it’s easy to “drop the ball” or “miss the mark”, on even the smallest of things. Periodic reviews of and updates to organizational policies and procedures is a very common candidate for oversight. We often tend to be laser focused on implementation and verification of highly technical controls that actively prevent incidents, and the more routine administrative controls can easily take the “back seat”. And when this happens, it’s easy to fall out of compliance.

There is a better way though, and more and more organizations are seeing the light at the end of the tunnel. DevSecOps is still a fairly new and “shiny” term, but it relates to security functions integrating with DevOps teams early and often, and building “paved paths” with “guardrails” into the process. Just how DevOps has increased the quality and speed of delivery of modern technology by building solid pipelines with lots of automated testing, so too can DevSecOps implement continuous integration and development principles.

Steps to Modernizing Your GRC or Risk Management Program

There are several key things that enable organizations to run GRC programs in a way that is more scalable and efficient, helping to move GRC from a perceived “cost-center” to a business accelerator. It’s not an easy path, but transitioning to DevOps was not an easy path either yet it has proven time and time again to not only be worthwhile but also to be extremely valuable.

1. Organizational Buy In

   To begin, there must be complete alignment amongst organizational leadership and at the board level to build a more sustainable and scalable way of doing GRC. This includes acceptance of “growing pains”, the added initial costs, and facilitating cross-organizational working groups. Everybody benefits from this arrangement-and it’s important to make sure key stakeholders understand how they are benefiting so they can enthusiastically buy-in and be champions for change.

2. Develop Relationships With Engineering

   Highly-technical teams are crucial allies in this endeavor. SaaS companies should always include Engineering and Site Reliability Engineering (SRE) Teams. The teams that are constantly deploying changes and keeping the “lights-on” are the star of the show here and it’s extremely important for modern GRC teams to work closely with, and embed into these teams.

   In my experience, this is hands down the most important relationship to develop for a modern GRC practitioner looking to modernize their program. Cross-training must happen between both the GRC experts and the technical teams. Neither team needs to be an expert in the other’s job but they both must have an understanding of how things work. SRE teams can benefit greatly by providing a condensed onboarding or job shadowing experience for GRC team members.

   At a minimum, tools used should be covered, especially any ticketing, change management and collaboration systems being used in the teams. A modern GRC practitioner benefits greatly when they work, when possible, in the tools that DevOps teams are already working from. This gives them the perfect perspective for assessing organizational security and thus compliance with your requirements.

3. Learn New Technologies and Methodologies

   I have managed multiple GRC initiatives and programs and one of the biggest lessons I’ve learned for us, the GRC practitioner, is that we must be ready to humble ourselves and learn. We must learn new technologies and methodologies that are being employed by DevOps teams. Many of us may have never used Git or other source code management systems, or have no idea what a markdown, YAML, terraform or JavaScript file looks like. We are all beginners at some point and that’s OK.

   Gaining a basic understanding of what tools and processes are in play with our teams at even the most basic level pays huge dividends. When we learn how these tools work together we greatly benefit all parties involved. In addition to our own person growth and development we must also teach these technical DevOps teams some basics about GRC. The key here is keeping it to the basics, just like a GRC practitioner shouldn’t be expected to learn complicated deployment and troubleshooting, our SRE teams shouldn’t be expected to lead an audit.

   We want SRE teams to understand:

   • The driving forces behind framework or standard requirements
   • The difference between meeting a requirement and meeting the intent of the requirement
   • How and why we must manage requirements from multiple frameworks and standards
   • What goes on as part of the audit process
   • Why we collect evidence and have a conversation around efficiencies we can put in place to make evidence collection consistent, reliable and less impactful to engineering teams

   Once these relationships are established and knowledge shared, you will find that DevOps teams will do what DevOps teams have always done, they will innovate away mundane, duplicative and frustrating work. Your organization will innovate solutions that meet your organization’s specific needs and you’ll see constant, measurable improvements.

   Camaraderie and trust will rise and GRC will start to shift from a cost center to a true business enabler. I can’t stress enough that it is hard work, but it’s the kind of hard work that leaves a lasting legacy and can leave you very proud of what you built.

4. Create a System of Record

   The final key in this approach is in moving to the system(s) of record. Sharing individual files is a recipe for disastrous results. Can you imagine a modern sales team managing their activities in spreadsheets as opposed to a true Customer Relationship Management (CRM) system?

   Of course not! So why then is it common practice for us to manage our GRC programs this way? But it’s important to understand that there will likely not be a single system of record. That’s why it’s critical for your GRC program to integrate with other sources of a vital system of record.

   Change management systems, asset management systems, document management systems (for policies and procedures) and ticketing systems are all key systems to integrate with. Having a system of record for GRC activities is extremely important and a modern purpose built solution like the RiskOptics ROAR Platform is the perfect choice!

RiskOptics Can Help

The RiskOptics ROAR Platform is purpose built to help solve challenges faced by modern GRC teams. ROAR provides a clear, easy to use system of record that can help with managing many of the processes addressed in this article.

The ROAR Platform gives you the ability to see, understand and take action on your IT and cyber risks. With a unified, real-time view of risk and compliance-framed around your business priorities — you’ll have the contextual insight needed to easily and clearly communicate with key stakeholders to make smart, strategic decisions that will protect your enterprise, systems and data, earning the trust of your customers, partners and employees.

To see the RiskOptics ROAR Platform in action, schedule a free demo today.