From tumultuous tech titans to greasy spoon diners, hardly anyone is exempt from the need to cut deals and rely on third parties to support critical aspects of their operations, services, and infrastructure. But if you enter into and treat these sensitive partnerships like a Las Vegas shotgun wedding, the promise of efficiency may mask a potential parade of risks that, if exploited, could be detrimental to an organization. This is where Third-Party Risk Management (TPRM) comes in, providing a structured approach to identifying, assessing, monitoring, and mitigating the possibility of these relationships going sideways.
In the great, paranoid banquet known as the cybersecurity community, there's quite a bit of chatter about TPRM’s effectiveness—we’ll get into that shortly. But this raises the question: when the suits from Regulatoryville decree that TPRM must be done, does its effectiveness even matter? Moreover, is there any legitimate argument against it when viewed through the lens of due diligence? If you can't at least concede that notion, then you're just a cynic spitting hate into the howling void.
From CISØ’s perspective, the curiosity, skepticism, and negative sentiment are valid and highlight the need for a more calibrated approach. With that, let’s discuss how we can turn TPRM from duct tape holding a monster together into a more effective, value-maximizing process for our clients. It won’t make the beast perfect, but it could prevent a potentially under-vetted relationship from unraveling into a puddle of liability and lost revenue.
Before we dive in, let's first identify which vendors get invited to the party. Here's a quick and simple gauge:
(CISØ NOTE: If your group decides to handle TPRM in-house, don’t hesitate to ask tough questions. Just because the vendor may be a large provider, your responsibility is to your company, not their ego. Never compromise on your security controls if a third party cannot meet your minimum requirements.)
.avif)
With this approach, the tester receives little to no information about the target system. A stranger in a strange land, plunging into a gambit with nothing more than a grim sense of purpose and a powerful lust for discovery. Black box is guerilla warfare, pure and simple. Every creak in the structure is a potential for advancement, every poorly guarded entry an opportunity, turning trial and error into a twisted art form.
Black box testing provides a controlled demonstration of how the system fares when an outside threat actor locks onto it. Of course, this kind of blind rampage does not account for the chewy, gooey center — and that is where the rub is. The tester might miss the deep-rooted, hidden problems buried in the system. And that is where white box testing comes in.
Here, the tester is handed a garage door opener (credentials) and floor plans (network and architecture diagrams). Armed with insider knowledge, they are more than just a tester. They are an attacker, using X-ray-capable Groucho glasses to disguise themselves as an auditor. White box testing aims to peel away every last layer of the system, hunting for vulnerabilities in source code, configuration slip-ups, and the logic flaws system admins might overlook when the tunnel vision of continuity and maintenance creeps in.
It is a strange intimacy, granting an outside force full disclosure and an unfiltered view, but it is a hell of a way to make sure you are not living on borrowed time.
Our calibrated approach focuses on taking inventory, ensuring visibility, and putting safeguards in place. You can't manage what you don't know about, and simply relying on a vendor to do the right thing in a timely manner is not good enough.
From tumultuous tech titans to greasy spoon diners, hardly anyone is exempt from the need to cut deals and rely on third parties to support critical aspects of their operations, services, and infrastructure. But if you enter into and treat these sensitive partnerships like a Las Vegas shotgun wedding, the promise of efficiency may mask a potential parade of risks that, if exploited, could be detrimental to an organization. This is where Third-Party Risk Management (TPRM) comes in, providing a structured approach to identifying, assessing, monitoring, and mitigating the possibility of these relationships going sideways.
In the great, paranoid banquet known as the cybersecurity community, there's quite a bit of chatter about TPRM’s effectiveness—we’ll get into that shortly. But this raises the question: when the suits from Regulatoryville decree that TPRM must be done, does its effectiveness even matter? Moreover, is there any legitimate argument against it when viewed through the lens of due diligence? If you can't at least concede that notion, then you're just a cynic spitting hate into the howling void.
From CISØ’s perspective, the curiosity, skepticism, and negative sentiment are valid and highlight the need for a more calibrated approach. With that, let’s discuss how we can turn TPRM from duct tape holding a monster together into a more effective, value-maximizing process for our clients. It won’t make the beast perfect, but it could prevent a potentially under-vetted relationship from unraveling into a puddle of liability and lost revenue.
Before we dive in, let's first identify which vendors get invited to the party. Here's a quick and simple gauge:
(CISØ NOTE: If your group decides to handle TPRM in-house, don’t hesitate to ask tough questions. Just because the vendor may be a large provider, your responsibility is to your company, not their ego. Never compromise on your security controls if a third party cannot meet your minimum requirements.)
The above is a common question vCISOs field on discovery calls. I can't speak for other groups, but here at CISØ, we have a collection of analogies we like to reference to illustrate both the difference and the correlation.
For this demonstration, I’ll choose the industry’s laziest and most overused example: the "home burglar" parallel. Ahem, *clears throat*..
"VA is a home inspector pointing out the rusted hinges and cracked jamb on your front door, while a pentest is a lunatic dual-weilding a sledgehammer and a crowbar, standing in your living room, having just kicked his way in."
I might've thrown a little mustard on that hotdog to give it some kick, but if my attempt to inject humor into this service description fell flat, here’s the gist: a vulnerability assessment finds potential problems, while a pentest examines how easily those problems can be exploited.
.jpg)
In conclusion, if you’re up for more of our patented, hilariously cynical analogies, just reach out!
Let's Chat!Our calibrated approach focuses on taking inventory, ensuring visibility, and putting safeguards in place. You can't manage what you don't know about, and simply relying on a vendor to do the right thing in a timely manner is not good enough.
From tumultuous tech titans to greasy spoon diners, hardly anyone is exempt from the need to cut deals and rely on third parties to support critical aspects of their operations, services, and infrastructure. But if you enter into and treat these sensitive partnerships like a Las Vegas shotgun wedding, the promise of efficiency may mask a potential parade of risks that, if exploited, could be detrimental to an organization. This is where Third-Party Risk Management (TPRM) comes in, providing a structured approach to identifying, assessing, monitoring, and mitigating the possibility of these relationships going sideways.
In the great, paranoid banquet known as the cybersecurity community, there's quite a bit of chatter about TPRM’s effectiveness—we’ll get into that shortly. But this raises the question: when the suits from Regulatoryville decree that TPRM must be done, does its effectiveness even matter? Moreover, is there any legitimate argument against it when viewed through the lens of due diligence? If you can't at least concede that notion, then you're just a cynic spitting hate into the howling void.
From CISØ’s perspective, the curiosity, skepticism, and negative sentiment are valid and highlight the need for a more calibrated approach. With that, let’s discuss how we can turn TPRM from duct tape holding a monster together into a more effective, value-maximizing process for our clients. It won’t make the beast perfect, but it could prevent a potentially under-vetted relationship from unraveling into a puddle of liability and lost revenue.
Before we dive in, let's first identify which vendors get invited to the party. Here's a quick and simple gauge:
(CISØ NOTE: If your group decides to handle TPRM in-house, don’t hesitate to ask tough questions. Just because the vendor may be a large provider, your responsibility is to your company, not their ego. Never compromise on your security controls if a third party cannot meet your minimum requirements.)
How we break down and scrutinize each crack in the system, naming the beast so you can set controls that aren’t seen as limits but boundaries between you and everything waiting to go wrong.
We meet with key decision-makers to define the scope of the assessment. Some elements that need to be defined are:
Organizational Overview:
Gain a comprehensive understanding of the organization’s structure (for example, number of employees, business units and departments, physical locations), operations (for example, core business processes, supply chain and third-party vendors), and key assets (for example, IT infrastructure, critical assets).
Regulatory Considerations:
We determine whether any applicable regulatory requirements, both industry-specific (for example, SEC, HIPAA, PCI-DSS) and geographical (for example, GDPR, CCPA), need to be considered and factored into the assessment.
Data Classification and Sensitivity:
Understanding how data is classified helps determine the full extent and scope. Our starting point is to identify the different types of data the organization handles (for example, PII, PHI, CHD, financial data), then proceed to identify how this data is collected, stored, and transmitted.
MSP/Internal IT Collaboration:
We work closely with your MSP or internal IT department to gather key information and ensure a thorough and accurate understanding of your organization's IT environment. Some areas of inquiry and request include an up-to-date asset inventory, detailed network and data flow diagrams, data classification, access control and user privileges, and backup and disaster recovery strategy, to name a few.
We conduct in-depth interviews with personnel across the organization, representing a wide range of access levels to systems and data, along with diverse responsibilities and leadership roles. These interviews allow us to analyze risk at a granular level where technology and human behavior intersect, which is crucial for identifying real-world risks that could impact your organization. Some of the elements assessed during the interviews include:
Technical/Endpoint:
• MFA
• Disk Encryption
• Patching and Updates
• Session Management (e.g., Computer Time-Out/Screen Lock, Auto-Logoff)
• Security Applications and Tools (e.g., AV, MDR, RMM, Password Manager)
User Behavior:
• Poor security practices
• Effectiveness of Training and Awareness
• Awareness and Adherence to Security Policies
• Susceptibility to social engineering attacks
Work From Home (WFH) and Travel Security:
• Management of Confidential Information in Home Environment
• Home Network Security Configs
• VPN Usage
• Public Wi-Fi Usage
• Physical Security of Devices
Simultaneously, we analyze the deliverables provided by your MSP or IT department, thoroughly reviewing systems, configurations, procedures, and documentation. Once we conclude this in-depth portion of the assessment, we evaluate our findings to determine the magnitude and likelihood of occurrence.
During this step, we evaluate (quantify) the cyber risks that have been identified and analyzed to determine their potential impact on your organization. We then prioritize these risks based on metrics that assess their significance.
A quick and dirty way to calculate the total risk exposure of an event is by considering both the severity of potential consequences (impact) and the probability of their occurrence (likelihood).
Simply put: Risk = Impact × Likelihood
Let's look at how we determine and define the two factors at play:
Likelihood: "How likely is it that this attack will occur?"
The probability that a specific threat will exploit a vulnerability within a given timeframe. This evaluation is informed by historical data, threat intelligence, environmental factors, and the effectiveness of your existing controls.
Impact: "How bad will it be if this attack occurs?"
The severity of the consequences should a threat exploit a vulnerability. We consider potential financial loss, reputational damage, operational disruption, and legal implications.
Calculating the likelihood and impact of an attack is a multifaceted process that requires a blend of data analysis, expert judgment, and continuous monitoring. Since many factors can influence the likelihood or impact of a risk, we must gauge the complexity of how we calculate (quantify) on a case-to-case basis, and tailor our approach accordingly. We also take into account the organization’s risk tolerance or appetite (how much risk they're willing to accept).
Once the risks have been evaluated, we prioritize them based on their potential to cause the most significant harm to the organization. Using prioritization as a guide helps in planning that resources—such as time, money, and personnel—are allocated to address the most critical threats first.
We base prioritization on several factors, including:
• Business impact
• Likelihood and ease of exploitation
• Availability of patches or mitigations
• Regulatory and compliance requirements
By addressing the most pressing risks and focusing on the 'priority of continuity,' we maximize the effectiveness of your information security risk assessment.
Once the assessment is complete, we create a thorough report on the engagement, ensuring that the results of the risk assessment are thoroughly captured. It is structured to allow different audiences, including executives, IT teams, and regulatory bodies, to easily glean pertinent information, enabling informed decision-making and action. For example, our executive report provides a high-level summary of the assessment, offering non-technical stakeholders, such as board members and executives, a clear overview of the findings.
When requested, we can brief relevant parties to clarify findings, enabling responsible teams to secure necessary resources and proceed with implementing mitigation strategies. Clear communication allows responsible parties within the organization to understand their roles concerning the identified risks.
Here are a few examples of the briefings we hold, the teams involved, and the topics discussed:
Executive Management and Board Members
• THE WHAT: Executive Summary, Key Findings and Priorities, Strategic Recommendations
• THE WHY: Strategic Decision-Making, Risk Appetite Alignment
IT and Security Teams
• THE WHAT: Detailed Risk Analysis, Controls Review, Vulnerability Assessment Scan Review
• THE WHY: Action and Implementation, Technical Guidance, Task Prioritization
Risk Management and Compliance Teams
• THE WHAT: Risk Register and Business Impact Analysis (BIA), Compliance Gaps and Recommendations
• THE WHY: Compliance Assurance, Regulatory Audit Preparation and Readiness
It is important to remember that an information security risk assessment captures only a snapshot in time. Since the vulnerability and threat landscape changes constantly, organizations should conduct assessments regularly and frequently, ideally alongside companion engagements such as vulnerability assessments. This approach helps organizations confirm that they have addressed vulnerabilities identified in previous assessments and enables them to detect new ones as they emerge.
You may notice a shift in verbiage with this step. That is because we must maintain impartiality as an external, unbiased assessor. We can only provide guidance, not perform remediation, to maintain objectivity, avoid conflicts of interest, and uphold regulatory standards.
For that reason, this section is listed as a "half-step" because, although it is an integral component of the risk assessment process, some groups absorb this responsibility themselves and forego the assessor’s counsel and direction.
That said, in the event an organization seeks XIVX to manage this piece of the assessment, these are a few of our offerings:
Risk Treatment Guidance: Before mitigation and monitoring occurs, we can assist in deciding which risks require the appropriate response, or risk treatment.
To do this, we align the risk with an approach:
Accept:
When a risk aligns with the organization’s risk tolerance or the cost of mitigation outweighs the potential impact, the organization may choose to accept it.
NOTE: If a client chooses this option, we will assist in creating a Risk Acceptance Form signed by senior management that specifies the reason for acceptance, the potential impact, and the risk tolerance level.
Mitigate:
Taking action to reduce the likelihood or impact of a risk to a more manageable level so it aligns better with the organization’s risk tolerance.
Transfer:
In some cases, an organization may decide to shift the responsibility of the risk to a third party that would absorb specific functions, or the cost of potential losses via cyber insurance. Transferring doesn’t eliminate the risk but shifts the burden.
NOTE: If a client chooses to transfer risk, we can assist in completing the cyber liability insurance forms and conducting vendor due diligence on potential solution providers.
Avoid:
Eliminating the risk by choosing not to engage in certain activities, processes, or partnerships. Avoidance is often considered when the risk is too high or doesn't align with the organization’s risk appetite.
Mitigation Implementation Guidance: We formulate (or assist in formulating) a strategic plan the remediation team (internal IT/MSP) will take to mitigate the identified risks. This could involve explaining potential solutions, suggesting relevant tools, or helping the client understand industry standards.
Monitoring Implementation Progress: We track the remediation team's progress in executing the mitigation plan and conduct follow-up assessments of the implemented controls to ensure they effectively mitigate the risks. This involves regular check-ins to review implementation efforts and determine the potential need for recalibration of plan or solution guidance. Through this process documentation, or evidence, is generated verifying that remediation actions have been performed and successfully implemented.
Service Provider Coordination: We can coordinate with third-party teams responsible for executing remediation activities by communicating requirements, ensuring the recommendations are clear, and supporting the remediation teams with additional context or clarification.
Our calibrated approach focuses on taking inventory, ensuring visibility, and putting safeguards in place. You can't manage what you don't know about, and simply relying on a vendor to do the right thing in a timely manner is not good enough.
From tumultuous tech titans to greasy spoon diners, hardly anyone is exempt from the need to cut deals and rely on third parties to support critical aspects of their operations, services, and infrastructure. But if you enter into and treat these sensitive partnerships like a Las Vegas shotgun wedding, the promise of efficiency may mask a potential parade of risks that, if exploited, could be detrimental to an organization. This is where Third-Party Risk Management (TPRM) comes in, providing a structured approach to identifying, assessing, monitoring, and mitigating the possibility of these relationships going sideways.
In the great, paranoid banquet known as the cybersecurity community, there's quite a bit of chatter about TPRM’s effectiveness—we’ll get into that shortly. But this raises the question: when the suits from Regulatoryville decree that TPRM must be done, does its effectiveness even matter? Moreover, is there any legitimate argument against it when viewed through the lens of due diligence? If you can't at least concede that notion, then you're just a cynic spitting hate into the howling void.
From CISØ’s perspective, the curiosity, skepticism, and negative sentiment are valid and highlight the need for a more calibrated approach. With that, let’s discuss how we can turn TPRM from duct tape holding a monster together into a more effective, value-maximizing process for our clients. It won’t make the beast perfect, but it could prevent a potentially under-vetted relationship from unraveling into a puddle of liability and lost revenue.
Before we dive in, let's first identify which vendors get invited to the party. Here's a quick and simple gauge:
(CISØ NOTE: If your group decides to handle TPRM in-house, don’t hesitate to ask tough questions. Just because the vendor may be a large provider, your responsibility is to your company, not their ego. Never compromise on your security controls if a third party cannot meet your minimum requirements.)
Our calibrated approach focuses on taking inventory, ensuring visibility, and putting safeguards in place. You cannot manage what you do not know about, and simply relying on a vendor to do the right thing in a timely manner is not good enough.
Based on scope, needs, budget, and compliance requirements, we help your team identify the most effective and efficient approach for evaluating the necessary third parties in your environment.
The two most common approaches here are Vendor Risk Assessment and Vendor Due Diligence. While conceptually similar, both serve distinct purposes and occur at different stages of the vendor lifecycle.
Here's a breakdown:
Vendor Due Diligence (VDD):
This is the initial process of evaluating a potential vendor before establishing a business relationship. It focuses on assessing the vendor's reliability, financial stability, regulatory compliance, security practices, and overall suitability. The goal is to determine whether the vendor can securely and reliably deliver their solutions to the client, along with identifying any operational or legal risks associated with the relationship.
(CISØ NOTE: An annual VDD may suffice for some groups as part of their ongoing TPRM process.)
Vendor Risk Assessment:
A broader, ongoing evaluation of a vendor that focuses on their performance, compliance, and any changes to their risk profile over time. This process includes identifying and prioritizing risks based on their potential impact and likelihood, while proactively mitigating them throughout the relationship lifecycle.
Vendor Risk Assessments are conducted during onboarding and at regular intervals (e.g., annually or based on risk level). They can also be triggered by significant changes in a vendor's operations or compliance status.
Defining clear security expectations in contracts, including SLAs, data handling protocols, and breach response requirements.
We work closely with legal teams to address key risks identified during TPRM assessments, ensuring contractual safeguards are implemented to mitigate deficiencies.
Continuously tracking third-party activities and security metrics to identify deviations, potential incidents, or changes in risk profiles as they occur.
Developing remediation strategies when a vendor fails to meet security standards, which may include mandating improvements or, if necessary, replacing the vendor.
Ensuring vendors adhere to relevant industry standards and regulations (e.g., GDPR, CCPA, HIPAA, PCI DSS), based on the firm's industry and location.
In the farthest recesses of the internet, there are message boards where GRC experts lament and debate with neatly trimmed moustaches (or, if you are a member of the fairer sex, in the comfort of Saks Fifth's finest: a brocade jacquard single-button blazer with matching broccato tapered pants). It's a real, uh, beehive of activity.
The topic? The importance of TPRM.
But much like the emperor's clothes, its effectiveness depends on where and how one chooses to look. A notion put forward by TPRM naysayers is this: asking third parties to complete standard security questionnaires about their overall security posture, even if it uncovers risks related to their internal practices or access to your systems, is of limited practical use.
We totally get the argument. But again, through the lens of due diligence, we have to disagree.
The way we see it here at CISØ, once those risks are identified, your options are usually limited to:
- Choosing a different vendor (which is often not feasible)
- Asking the vendor to improve (though you'll often hear, "Yeah, it's in our infosec backlog," and end up waiting for years)
- Accepting the risks (the most common outcome)
Ultimately, risk acceptance is the most common outcome of any TPRM finding related to a third party's internal security posture. After all, you cannot control their security program, and, like it or not, you have very little influence over it.
When groups like CISØ collect questionnaires for their clients, how can we be sure the vendor's answers are true and accurate? Even if a costly and time-consuming deep-dive risk assessment is performed to verify, how can anyone know whether a vendor achieved ISO or SOC certification but then reverted to poor practices? We can't! And not all organizations can afford real-time monitoring of their third parties to maintain a persistent heartbeat on their vendor's security model.
For our clients, TPRM serves as a due diligence cog in the wheel of their overall security model. We do the best with what we are working with in terms of our clients' needs, budgets, and the vendors in question. We maintain realistic expectations regarding outcomes to provide appropriate guidance. As previously mentioned, we are able to work closely with legal teams to address key risks identified during TPRM assessments, ensuring that contractual safeguards are implemented to mitigate deficiencies.
Engaging CISØ helps organizations that lack the resources to build strong internal TPRM teams and processes become more nimble and respond more efficiently. At a minimum, it provides them with the opportunity to pause, reflect, and respond.
Our calibrated approach focuses on taking inventory, ensuring visibility, and putting safeguards in place. You can't manage what you don't know about, and simply relying on a vendor to do the right thing in a timely manner is not good enough.
From tumultuous tech titans to greasy spoon diners, hardly anyone is exempt from the need to cut deals and rely on third parties to support critical aspects of their operations, services, and infrastructure. But if you enter into and treat these sensitive partnerships like a Las Vegas shotgun wedding, the promise of efficiency may mask a potential parade of risks that, if exploited, could be detrimental to an organization. This is where Third-Party Risk Management (TPRM) comes in, providing a structured approach to identifying, assessing, monitoring, and mitigating the possibility of these relationships going sideways.
In the great, paranoid banquet known as the cybersecurity community, there's quite a bit of chatter about TPRM’s effectiveness—we’ll get into that shortly. But this raises the question: when the suits from Regulatoryville decree that TPRM must be done, does its effectiveness even matter? Moreover, is there any legitimate argument against it when viewed through the lens of due diligence? If you can't at least concede that notion, then you're just a cynic spitting hate into the howling void.
From CISØ’s perspective, the curiosity, skepticism, and negative sentiment are valid and highlight the need for a more calibrated approach. With that, let’s discuss how we can turn TPRM from duct tape holding a monster together into a more effective, value-maximizing process for our clients. It won’t make the beast perfect, but it could prevent a potentially under-vetted relationship from unraveling into a puddle of liability and lost revenue.
Before we dive in, let's first identify which vendors get invited to the party. Here's a quick and simple gauge:
(CISØ NOTE: If your group decides to handle TPRM in-house, don’t hesitate to ask tough questions. Just because the vendor may be a large provider, your responsibility is to your company, not their ego. Never compromise on your security controls if a third party cannot meet your minimum requirements.)
Though closely related and often overlapping, they each focus on different aspects of protecting data and systems within an organization. For illustrative purposes, imagine them as two paranoid ends of the guest services spectrum within the exclusive Club Med that is your organization's systems.
Cyber P&P is the bouncer stationed around the perimeter and entrances, checking IDs, managing the crowd, and stopping the erratic and unruly from crashing your digital party. He deals with digital drunks, cyber punks, and the waitstaff trying to sneak friends in through the back. It is all about defending against the cybernefarious, regardless of which side of the VIP rope the shenanigans originate from.
And then there's Infosec P&P, the data concierge—the one who knows your name, your preferences, and, most importantly, where you keep your valuables.
The concierge does not care where the data parties: on your hard drive, in the cloud, or on a thumb drive. His job is to ensure the information you entrust to him remains as you left it: confidential, integral, and available. A distinguished man of service who embodies CIA: Confidentiality, Integrity, and Availability. Not the spy game, but the security game.
At CISØ, we recognize the symbiosis. We create a master blueprint simply named "Information Security Policies and Procedures," with Cybersecurity P&P incorporated as a subset. This approach encompasses all forms of data, establishing a unified strategy to ensure a holistic defense against the forces of entropy threatening to consume the entirety of everything.
Let's Chat!In cyber and information security, standards, guidelines, and procedures are key components that support and operationalize an organization's policies.
"All employees must use complex passwords and change them every 90 days to protect company data."
"Passwords must be at least 12 characters long and must include a mix of uppercase letters, lowercase letters, numbers, and special symbols."
"To change your password: 1) Go to settings; 2) Click 'Change Password'; 3) Enter current password; 4) Enter a new password following the password standard; 5) Confirm new password; 6) Click 'Submit'."
"It is advisable to use passphrases or sentences that are easy for you to remember but hard for others to guess."
Policies are the house rules, setting the "what" and "why." Standards and procedures define the "how," and guidelines offer additional support on the "how," providing flexibility and suggestions for effective security management.
At the end of the day, "Policies and Procedures" is often the title given to a document that contains a mix of all four components. At CISØ, we tailor this documentation to fit each client's needs appropriately.
I may seem pedantic here, but with good reason. It is imperative that all relevant parties understand the differences and interconnections. Policies represent an organization's official stance and commitment to security, requiring internal ownership and top-level approval. Standards are technical and specific, demanding in-depth knowledge of systems and processes. Procedures require detailed knowledge of internal systems, workflows, and tools, while guidelines are flexible recommendations that benefit from both internal insights and external expertise.
With CISØ running point, we ensure that policies and procedures are thoroughly scrutinized, developed, and written to uphold the organization's security model while helping them exceed compliance and regulatory requirements.
Our calibrated approach focuses on taking inventory, ensuring visibility, and putting safeguards in place. You can't manage what you don't know about, and simply relying on a vendor to do the right thing in a timely manner is not good enough.
From tumultuous tech titans to greasy spoon diners, hardly anyone is exempt from the need to cut deals and rely on third parties to support critical aspects of their operations, services, and infrastructure. But if you enter into and treat these sensitive partnerships like a Las Vegas shotgun wedding, the promise of efficiency may mask a potential parade of risks that, if exploited, could be detrimental to an organization. This is where Third-Party Risk Management (TPRM) comes in, providing a structured approach to identifying, assessing, monitoring, and mitigating the possibility of these relationships going sideways.
In the great, paranoid banquet known as the cybersecurity community, there's quite a bit of chatter about TPRM’s effectiveness—we’ll get into that shortly. But this raises the question: when the suits from Regulatoryville decree that TPRM must be done, does its effectiveness even matter? Moreover, is there any legitimate argument against it when viewed through the lens of due diligence? If you can't at least concede that notion, then you're just a cynic spitting hate into the howling void.
From CISØ’s perspective, the curiosity, skepticism, and negative sentiment are valid and highlight the need for a more calibrated approach. With that, let’s discuss how we can turn TPRM from duct tape holding a monster together into a more effective, value-maximizing process for our clients. It won’t make the beast perfect, but it could prevent a potentially under-vetted relationship from unraveling into a puddle of liability and lost revenue.
Before we dive in, let's first identify which vendors get invited to the party. Here's a quick and simple gauge:
(CISØ NOTE: If your group decides to handle TPRM in-house, don’t hesitate to ask tough questions. Just because the vendor may be a large provider, your responsibility is to your company, not their ego. Never compromise on your security controls if a third party cannot meet your minimum requirements.)
It is a tragic comedy we have seen play out too many times: organizations throwing their cash and sanity into the abyss of playbook hell. A mountain of playbooks, each one polished to a bureaucratic sheen, yet destined to rot in some forgotten folder. One group spent months (and an untold amount of money) building a gold-plated "perfect" ransomware playbook, only to choke when the real deal came knocking.
1.) Keep it simple. Create six high-level playbooks for the most common scenarios and tabletop them to hell and back. Revise your documentation after each exercise. If they are not in use, they are dead weight. Delete them. Like everything else in infosec, if it does not evolve, it is a liability, not an asset.
2.) Adapt or die. Stop trying to script every move. Real crises will not follow your script. Teach your team to improvise, adapt, and respond. A sharp mind beats a perfect playbook every time. Invest in the people, not the paper. When the breach comes, they will thank you.
Overly specific playbooks lull you into a false sense of security. They do not prepare you; they pacify you, numbing the brain and killing off the instinct, creativity, and critical thinking you need when the digital shitstorm hits.
The real benefit lies in honing your team's ability to make calls in the heat of an actual incident, not in amassing unread directives. A playbook will not save you. Your people will. If you want to survive, train them for the world as it is, not as you wish it were.
Let's Chat!If you subscribe to our mantra of disregarding the check-the-box mentality and you approach your GRC requirements through the lens of cybersecurity, then heed this advice: hire an outside facilitator (vCISO) to oversee or audit your IRP preparedness. Cybersecurity is not a compliance-by-numbers game. It is trench warfare.
“No one is a prophet in their own land.”
With an external facilitator like CISØ, you gain insights into what the industry at large is doing. Individual employees or teams may be too close to the problem to see it clearly. They are like chefs who have been in the kitchen too long, nose-blind to the smell of something burning. Consultants get a fresh look, with a back catalog of knowledge and experience that comes from assessing hundreds of other organizations. We have seen it all — what works, what does not, and what explodes spectacularly.
A report from a consulting firm comes at an additional cost, and whether it is right or wrong, that carries more weight with executive leadership than one from an internal resource. But intuitive security groups operating internally, wading through bureaucratic mud, will use us advantageously as a hammer to get their initiatives across the finish line.
Plus, external facilitators can dial down the heat if the TTX starts to boil over. Exercises expose fractures: turf wars, bruised egos, and dysfunctional processes. When IT or security calls out another group, it can feel personal. A neutral facilitator like CISØ smooths the rough edges, ensuring everyone’s voice is heard and the focus stays on collaboration. No egos, no agendas, just results.
Communicating the critical nature of Incident Response Preparedness to the C-suite requires decoding cyber risks into a language they understand: business impact. Often, the importance of this entire process may be lost on some senior leaders and even key players identified in the IRP. To address this, we often begin with a "What is Cyber Risk?" briefing (though we use a different title to ensure the intended audience takes it seriously). This briefing targets individuals and groups who, in one breath, admit to seeing cybersecurity as nothing more than a cost center or inconvenience, but in the next, launch into a tirade about the devastating impact of losing email for just a day.
Connect the dots between cybersecurity gaps and the operational chaos and financial fallout they cause, and that upfront alignment can be what transforms skepticism into buy-in.
Many cyber risks are dismissed by senior leadership simply because they seem improbable. Therefore, paint the probability of occurrence in the blood of impact on operations, GRC liabilities, and consequences.
Success often hinges on how risks and gaps are presented. A common challenge is the siloing of IT and security metrics versus broader business metrics, which can lead to senior leadership disengaging. With a third party like CISØ leading the effort, the internal security team is prevented from trying to "hero" the problem away. This forces leadership to confront the business impact of a potential incident.
A parlance that frames the exercise in an executive-level context, bridging the gap between resilience and incident response. When you speak their language, the message sticks, and they are paying attention the next time around.
Let's Chat!Yeah, that might sound like a fever dream you want no part of, but hear us out...
How can we transform an otherwise boring and dry simulation into an engaging, memorable learning experience that keeps participants invested and better prepared for real incidents?
The old way of running simulations was a death march of tedium, the kind of thing that made participants stare longingly at the exit sign.
Cybersecurity awareness training went through the same grim phase: bland, unpalatable, and outright offensive in its mundane approach. People did not learn; they endured. But then someone had the bright idea to add production value. Now, slick, CSI-style episodes make it at least tolerable and stickier in the brain.
At CISØ, we cranked the dial further by gamifying incident simulations. Think dice rolls to dictate scenario twists, a "crisis momentum" meter to track escalating chaos, and branching storylines that force participants to think on their feet. Add story cards to inject curveballs, and suddenly you have something closer to a tabletop RPG than a corporate exercise. We are not just preparing your team for incidents; we are making you live through them, in a controlled yet chaotic dance of chance and strategy.
Author’s Confession: Unlike many of my counterparts in this field, I have never rolled a d20 myself. However, after designing and conducting some of our simulations, I can now (kind of) appreciate its appeal.
Our calibrated approach focuses on taking inventory, ensuring visibility, and putting safeguards in place. You can't manage what you don't know about, and simply relying on a vendor to do the right thing in a timely manner is not good enough.
From tumultuous tech titans to greasy spoon diners, hardly anyone is exempt from the need to cut deals and rely on third parties to support critical aspects of their operations, services, and infrastructure. But if you enter into and treat these sensitive partnerships like a Las Vegas shotgun wedding, the promise of efficiency may mask a potential parade of risks that, if exploited, could be detrimental to an organization. This is where Third-Party Risk Management (TPRM) comes in, providing a structured approach to identifying, assessing, monitoring, and mitigating the possibility of these relationships going sideways.
In the great, paranoid banquet known as the cybersecurity community, there's quite a bit of chatter about TPRM’s effectiveness—we’ll get into that shortly. But this raises the question: when the suits from Regulatoryville decree that TPRM must be done, does its effectiveness even matter? Moreover, is there any legitimate argument against it when viewed through the lens of due diligence? If you can't at least concede that notion, then you're just a cynic spitting hate into the howling void.
From CISØ’s perspective, the curiosity, skepticism, and negative sentiment are valid and highlight the need for a more calibrated approach. With that, let’s discuss how we can turn TPRM from duct tape holding a monster together into a more effective, value-maximizing process for our clients. It won’t make the beast perfect, but it could prevent a potentially under-vetted relationship from unraveling into a puddle of liability and lost revenue.
Before we dive in, let's first identify which vendors get invited to the party. Here's a quick and simple gauge:
(CISØ NOTE: If your group decides to handle TPRM in-house, don’t hesitate to ask tough questions. Just because the vendor may be a large provider, your responsibility is to your company, not their ego. Never compromise on your security controls if a third party cannot meet your minimum requirements.)
It’s simple psychology (and, we’d argue, physics): a live, interactive, open forum that is instructor-led resonates with people on a deeper level. And by instructor-led, we mean your vCISØ (think: creative, witty, a subject matter expert who is easy on the eyes).
Our live cybersecurity awareness training looks a bit like this:
However, we have noticed that tying the professional training to personal benefits makes it much more memorable and impactful.
That is why we tailor training sessions on a tiered basis, addressing groups like everyday staff, power users, and the C-suite.
For everyday staff, we eliminate as much technical terminology as possible and use analogies that non-technical employees can relate to. We focus on simple yet impactful cybersecurity practices, such as adopting MFA and password managers.
We use spam emails your company has received and real-world screenshots to depict examples of common cybersecurity threats that directly impact your team. We do not bore your accounting, HR, and operations teams with detailed explanations of DDoS attacks or the finer points of SQL injection techniques.
That means we come with real-world stories (often grounded in un/diagnosed cyber-PTSD) and props. For example, in real-world or video conference training, one of us may bring out a paper bag containing $31,337 in Amazon gift cards. This illustrates the dangers when, for instance, a new hire in Finance posts about their job on social media and receives a phishing email from a fake CEO asking for a “special job” involving employee recognition.
If this is your organization’s first time working with a group like XIVX, we may be writing your Information Security Policies and Procedures. This might include creating your first-ever WISP (Written Information Security Program). Governance policies help manage discretionary controls, since not all controls can be mandatory or technical. We can incorporate your Cybersecurity Governance Policies into your training program. For example, Password Policies, Acceptable Use Policies, Information Handling Policies, and the WISP.
Our calibrated approach focuses on taking inventory, ensuring visibility, and putting safeguards in place. You can't manage what you don't know about, and simply relying on a vendor to do the right thing in a timely manner is not good enough.
.png)
.png)
.png)
