Risk Management and security are one of if not the biggest issue facing art organizations today. Unfortunately, it is not just because it may prove daunting but because it is rarely taken seriously within the organization until trouble arises.
Gone are the days when acquiring a HiTrust Certification, SOC2 type 2 auditor’s report, or an ISO 27001 accreditation was enough to defend your firm appropriately. Many seasoned practitioners knew that such a milestone was never a reliable indicator of an organization’s security posture or maturity. And it appears that the rest of the world has finally caught on.
The security threat environment is expanding in tandem with legislative and governance needs. Attacks have become more numerous and sophisticated, the number of attack channels has increased, the attack surface for businesses has increased substantially, and the complexity of our digital footprint has increased even further. In addition, the severe shortage of qualified and available workers to fill security tasks, including Governance, Risk, and Compliance (GRC), compounds the problem.
In short, GRC leaders face numerous hurdles in today’s firms. Yet, surprisingly, I hear little talk regarding the most efficient ways to run a modern GRC or risk management program. Because each firm is unique, there may be a variety of answers. There are, nevertheless, methods for modernizing your procedures.
- Do you have a Risk Management Program in place?
- How are you currently managing risk?
- Why has technology changed so dramatically while GRC programs have remained the same?
- Is there a more efficient way to manage today’s modern GRC program?
Before we begin discussing possible solutions, let’s review the basics:
Governance refers to an organization’s statutory or contractual obligations regarding security, risk, and privacy objectives. Noncompliance can result in severe fines and even criminal prosecution in some situations.
Risk refers to managing risk within an organization, focusing on security and privacy standards.
However, this merges with Enterprise Risk Management. Enterprise risk management (ERM) is detecting, analyzing, and treating a company’s risks based on an ongoing assessment by executive management. ERM includes examining the company’s exposures in financial, credit, fraud, strategic, and operational problems.
Compliance refers to an organization implementing security and privacy controls to meet governance standards and decrease risk. Internal and third-party external audits are a significant component of compliance.
My personal experience is firmly rooted in the NPO space, having spent the last 20 years helping many of our art clients with their IT audit and compliance. Based on that, I have some thoughts.
The sheer number of regulatory requirements a modern NPO must meet can be overwhelming. Similarly, managing organizational politics in an NPO is challenging, both for and against risk containment. Security, particularly GRC, has typically been viewed as a cost center rather than a value generator. And as I have stated in previous conversations, seen as a barrier to creativity.
Personnel shortages and burnout are at an all-time high, compounding the problem. According to industry analysis, this gap will continue to increase in the near term and will be a concern for quite some time.
Every day, we hear about one breach or another, and everyone is trying to move towards a more secure posture. However, these areas have financial consequences and criminal prosecutions due to a lack of monitoring and care.
In today’s environment, the message is clear: No matter what problems companies face, they must reasonably preserve the security and privacy of the data.
Running a Risk Management Program
A comprehensive alignment among the leadership is required to establish a more sustainable and scalable approach. Accepting “growing pains,” the additional initial costs, and facilitating cross-organizational working groups are all part of this. Everyone benefits from this arrangement, and key stakeholders must understand how they may help so that they can passionately buy in and be change champions.
To start the process, you must determine what regulatory obligations your firm should meet. The correct response would be, “Ask your auditors when they come in,” however, most auditors assign their most junior, fresh off-the-robe (just out of college) individuals to manage in-house audit interactions. So your best bet is for your Finance Officer to call one of your audit firm’s senior partners and obtain a summary of the regulations you must follow.
After defining the requirements, the hard work can begin, which begins with a thorough understanding of the organization’s environment. For example, what people, procedures, and technology does the organization have? What is the organization’s culture? What is the organization’s risk tolerance?
What is the organization’s risk tolerance? If you can’t answer these questions, you can’t assess compliance adequately. During this phase, we are attempting to piece together several essential views of the organization:
- Purpose, vision, and operational needs
- Lines of business
- Organizational Structure
- Key business processes
- The digital and physical footprint
- Assets
- Data processing and storage
Traditionally, there are numerous emails, direct messages, and meetings. As a result, all parties involved experience duplicative manual processes, exhaustion, and dissatisfaction. It’s simple to “drop the ball” or “miss the mark” on even the tiniest of tasks in the traditional way.
You will need a SecOp person to gather the data and get the closest approximation of the organizational reality. This person must have sufficient power to assemble and distill the information for executive review.
SecOps is a relatively new concept that refers to security functions collaborating with DevOps teams (Development and IT) early and frequently and incorporating “paved roads” with “guardrails” into the process.
The teams that are continually maintaining the environment, deploying updates, and keeping the “lights on” are the stars of the show here (DevOps), and it is critical for modern GRC teams (SecOps) to collaborate and integrate with these teams. The most vital connection to cultivate for a modern GRC practitioner wanting to update their program is this one. Cross-training between GRC experts and technical teams is required. Both groups can be experts in the other’s field but must grasp how things function.
Gaining a rudimentary awareness of what tools and processes are in use with DevOps offers significant returns. When we understand how these tools interact, we benefit all parties involved. Therefore, in addition to our personal growth and development, we must teach these technical DevOps teams the fundamentals of GRC. The idea here is to keep it simple; just as a GRC practitioner can’t master complex deployment and troubleshooting, neither should our DevOps teams be expected to lead an audit.
At the very least, the audit should address any commerce, ticketing, change management, and collaboration systems utilized in the teams. A modern GRC practitioner benefits immensely from working with the tools that DevOps teams are already using. Working with DevOps provides those practitioners with the ideal perspective for evaluating organizational security and, as a result, compliance with your criteria.
At the same time, the DevOps teams need to gain an understanding of the following:
- The forces influencing framework or standard requirements
- The distinction between completing a requirement and meeting the requirement’s intent
- How and why must we manage requirements from many frameworks and standards?
What happens during the audit process, why do we gather evidence, and what efficiencies can we put in place to make evidence collecting more consistent, trustworthy, and less impactful on engineering teams
Moving to the system(s) of the record is the final key in this method. Individual file sharing is a formula for disaster.
Can you envision a modern sales team organizing their activities through spreadsheets rather than a sophisticated Customer Relationship Management (CRM) system?
Certainly not! So, why do we handle our GRC initiatives in this manner regularly? First, however, it is critical to note that there will likely not be a single system of record. That is why your GRC software must integrate with other sources of a critical system of record.
Critical systems to integrate include change management systems, asset management systems, document management systems (for rules and procedures), and ticketing systems.
In short, make sure your IT and development crew know their systems, bring in an outside security person to lead the SecOps effort, and keep complete records of every process, discovery, and solution.
Sources:
GRC: The Definitive Guide (https://riskonnect.com/resources/grc-guide/)
THE ESSENTIAL GUIDE TO GRC (https://tallyfy.com/guides/governance-risk-management-compliance-grc/)
Risk and compliance management made easier (Hitrust- MyCSF)
(https://hitrustalliance.net/documents/mycsf/mycsf_information/MyCSFRiskAndComplianceManagement.pdf)
Behnam Ataee, DWG CTO, has completed the HITRUST CSF Assurance Program certification. Certified HITRUST CSF professionals can deliver simplified compliance assessments and report for HIPAA, HITECH, state, and business associate requirements.