Every OSINT analyst has been there. You pulled the threads, mapped the connections, built the timeline. The data looks clean and the narrative holds. Then someone asks a question you didn't consider and the whole picture shifts. The failure was not in your tooling or your collection. It was in your reasoning. The missing discipline in information security is not technical. It is intellectual.

The Cognitive Blind Spot in Security

We spend enormous energy mastering technical tradecraft. We learn to pivot across data sources, chain identifiers, verify imagery and attribute infrastructure. We build workflows, automate enrichment and refine our toolkits constantly.

But when was the last time you systematically trained the thing that actually interprets all of that data? when was the last time you trained your mind?

The uncomfortable truth is that most of us are running sophisticated collection on top of undisciplined analysis. We know how to find information. We are far less practiced at thinking about it rigorously. Confirmation bias does not announce itself. Neither does anchoring, narrative fallacy or the dozen other cognitive traps that plague analytical work. These are not problems you solve with better OSINT tools. They are problems you solve with better thinking.

An Ancient Framework for a Modern Problem

There is nothing new about this challenge. For over two thousand years a formal system existed for training exactly this capacity. The Trivium. Three disciplines studied in sequence. Grammar, Logic and Rhetoric. Grammar teaches you to define your terms precisely and understand the structure of what you are examining. Before you investigate, make sure you actually understand what you are looking at. How many investigations have gone sideways because an analyst confused correlation with connection or failed to define the scope of what they were actually trying to answer? Logic trains you to construct valid arguments, identify fallacies and stress test claims under scrutiny. This is the analytical core.

The discipline of asking whether your conclusion actually follows from your evidence or whether you have built a comfortable story around cherry picked data points. Rhetoric is the ability to communicate findings with clarity and force. Every OSINT professional who has written an intelligence product knows the gap between having good findings and delivering them in a way that drives action.

A brilliant investigation that produces an incomprehensible report is a wasted investigation. These are not abstract academic concepts. They map directly onto the intelligence cycle. Define the problem, analyse the information, communicate the assessment. The ancients understood something we have largely forgotten.

These are trainable skills, not innate talents.

Why This Matters Now More Than Ever

The information environment is getting worse, not better. AI generated content, synthetic media, coordinated inauthentic behaviour and the sheer volume of data available to analysts all compound the challenge. The bottleneck is no longer access to information. It is the ability to think clearly about what that information means. Every year the OSINT community gets better tools and every year the adversaries get better at poisoning the well. The asymmetry does not resolve with more automation. It resolves with sharper minds. Consider how much of modern security discourse is driven by reaction rather than reasoning.

A new threat report drops and the takes fly, often before anyone has critically examined the methodology, the sourcing or the assumptions behind the conclusions. We reward speed of opinion over quality of thought.

That is not analysis. That is performance. The professionals who consistently produce reliable intelligence are not the ones with the most tools or the fastest takes. They are the ones who have trained themselves to slow down at the critical moment. To define terms carefully, test their logic honestly and communicate their findings precisely. They practice the Trivium whether they call it that or not.

Building the Discipline

This is what led to the creation of Trivium Prime, that and the low level of discourse in British OSINT circles. A structured training ground for exactly this kind of intellectual formation. Not a course you watch passively. Not a certificate you collect. A disciplined practice built around mastering the foundational skills of clear thinking, honest reasoning and authoritative communication.

The programme is built around progressive levels. Foundations in logic, rhetoric and the grammar of knowledge. Then strategic intelligence covering political systems, economic structures, decision making frameworks and historical case studies. Then leadership, institution building and applied strategy. Members advance through demonstrated mastery, not attendance. You test. You defend your reasoning. You earn your rank. It is structured as a selective membership order, not an open platform. Admission requires an application and the barrier is intentional. This kind of training only works with people who are serious about it.

The Call

If you work in OSINT, threat intelligence or any discipline where the quality of your thinking determines the quality of your output, ask yourself honestly. When did you last train that capacity with the same rigour you apply to your technical skills? Most of us never have. We learned to think by accident, picking up habits from mentors, from experience, from making mistakes in the field. Some of those habits are good. Some of them are invisible liabilities we have never examined.

The Trivium Way offers a systematic alternative. A framework that has produced clear thinkers for millennia, now adapted for men who take their intellectual development as seriously as their professional development. Trivium Prime is accepting applications. If you are the kind of person who reads Secjuice you already care about doing this work well. The question is whether you are willing to sharpen the one tool that every other tool depends on.

Your mind is your primary sensor. Train it accordingly.

Trivium is a hobby project, come help me.

The format hasn't fundamentally evolved in decades. Jeopardy, King of the Hill, Attack/Defense, those three buckets cover essentially everything competitive CTF has produced, and the innovation inside them is almost entirely in challenge content, not game mechanics. Harder reversing. Cleverer crypto. More obscure forensics. Same skeleton, just dressed differently. Its getting boring.

The people who run serious CTFs are generally speaking, deeply sophisticated technically and almost completely unsophisticated as game designers. They've never had a reason to think about commitment mechanics, economic tension, or information pricing, because nothing in their world modeled it.

That's the gap, and it's larger than most people in the space have noticed.

The Three CTF Problems Nobody Is Fixing

Passive play is endemic. Even the top teams sandbag, they watch the scoreboard, patiently wait for others to partially solve the thing, and then they sprint at the end. The meta rewards this. Nobody likes it. Nobody has fixed it. The reason nobody has fixed it is that the game mechanics actively invite it, there is no cost to waiting, no exposure for hesitating, no penalty for riding information produced by others.

Prize pools feel arbitrary. You win because you scored the most points. Yawn. The connection between risk taken and reward earned is essentially zero. There's no moment where a player genuinely bled for the win, no public commitment, no skin in the game, no irreversible decision they had to live with. The prize is just a number attached to a leaderboard.

Spectators have nothing to watch. CTF is nearly unwatchable as a competitive spectator experience because there is no declared tension, no visible commitment, no moment of exposure. Players operate entirely inside their own heads until the moment of submission. Nothing is staked publicly. Nothing happens in the open that an audience can track or feel.

The Decision CTFs Never Ask For

Standard CTF is a game of complete commitment with zero timing risk. You either solve the challenge or you don't. There's no moment where you have to decide whether your partial understanding is good enough to act on. You sit with the problem until you crack it, then you submit. Thats it.

The decision is binary and entirely internal. The player is never exposed. They operate in private, they submit in private, and the only cost of being wrong is a minor point penalty or a failed attempt counter.

All of this means CTF has never asked what I think is the most interesting question in competitive gaming. When do you move on partial information?

This is the question that makes poker worth watching. It's the question that makes markets worth studying. It's the question at the core of every genuinely high-stakes decision, military, financial, strategic. You hold some information. Not none, not enough. Some. And something is forcing the live question.

Is what I know now worth acting on, or do I wait?

Waiting isn't free. Someone else might move. The next piece of intelligence costs something. Your window narrows. Acting isn't free either. You might be wrong. And the moment you commit, you've declared, which is itself information to everyone watching. That tension, act on partial information versus wait for more certainty, is the core cognitive and psychological experience that the competitive CTF ecosystem has never once tried to engineer. Its just not on their radar.

What a Better Format Looks Like

The mechanics already exist. They just haven't been applied here.

Take Jeopardy-style CTF. Instead of all challenges open simultaneously, each flag is gated behind a progressive clue chain. Solving clue N costs you something, a token, a time delay, a stake, and unlocks clue N+1. First solve takes the bounty. Suddenly players aren't just racing on technical skill; they're making timed economic decisions about which challenge to commit to, and when.

Take King of the Hill. Instead of "hold the server," you hold a physical object or location. Clues narrow the field progressively to a geographic zone. The player who reaches it and submits proof owns the hill. Displacing them requires someone else committing resources and moving. That's a real-world execution layer that purely digital king of the hill has never had.

Take Attack/Defence. The information as currency model applies directly to intelligence about opponents. Teams can purchase partial intelligence about the other team's infrastructure, intel that gets more precise as more is spent. The meta-game becomes do you invest in offensive intelligence, or defend blind?

In every case, the injection is the same. Commitment mechanics that punish passive play, economic skin-in-the-game beyond time investment, and the "when do I move" decision as a first-class part of the competition.

What This Isn't

This isn't an argument that CTF challenges should be easier, or that the technical bar should drop. The point isn't to make the puzzles more approachable. It's that the game design layer sitting above the technical challenges has been ignored.

The best technical competitors in the world are being run through a game that was designed in the 1990s and hasn't been seriously reconsidered since. The result is a format that rewards a specific kind of isolated, low-risk, information-complete problem-solving, and we call this competition?!

Real competition involves exposure. It involves irreversible decisions made under uncertainty. It involves a moment where you put something on the line and the outcome is genuinely in doubt. CTFs as currently designed don't have that moment. And until they do, the ecosystem will keep producing technically impressive events that feel, structurally, like homework.

The Format Already Exists

Everything described in this piece, the commitment mechanics, the progressive information release, the economic skin-in-the-game, the moment where a player has to decide whether what they know is worth acting on, these aren't design proposals. They're a description of a system that has already been built.

Hashclue is a physical cryptographic treasure hunt protocol. Clues are released progressively and priced. The cache is real and located in the world. Commitment is on-chain and irreversible. The moment of decision, move now on partial information, or wait and risk someone else getting there first, is not a side effect of the design. It is the design. It is, structurally, everything CTF forgot to become.

The technical challenge of finding the cache is real. The economic tension of when to move is real. The physical execution, your body, a location, proof of presence, is real. None of it happens inside someone's head in private.

All of it is exposed, staked, and irreversible.

The modern CTF ecosystem is optimising for technical difficulty, but Hashclue optimises for something harder, judgment under uncertainty.

The cache is already out there. Nobody has found it yet.

Most people who read this won't play. The ones who do will understand immediately why CTF never prepared them for Hashclue.

Part 2 of a series on creating information security policies

Many breaches don’t start with sophisticated hackers; they start with ordinary users doing ordinary things in unsafe ways. Let’s look at 3 ways to work toward helping people in our organizations understand better how to safeguard everyone’s information.

Because there are as many ways to create a policy as there are organizations - compounded with the numerous requirements from regulations - I won’t attempt to provide a one-size-fits-all policy for each of these. Part of the process of becoming a professional with policies is learning about all the options while also satisfying the requirements of your org. I’ve provided several links in the Resources section at the end of this article so you can check out options if you need inspiration or a headstart.

1)   Acceptable Use Policy

This policy defines how employees and contractors may use company systems, networks, and data. It sets boundaries for acceptable behavior and reduces ambiguity during investigations.

2)   Security Awareness & Training Policy

This establishes requirements for onboarding and ongoing security education. The goal isn’t perfection, but consistent, informed, job-role appropriate activities. Often, this needs to be hand-in-hand with Human Resources to ensure proper coverage for the lifecycle of one’s employment, from recruiting to offboarding.

3)   Remote Work Policy

The remote work policy addresses security expectations for working outside controlled environments, including device security, network usage, and data handling. This policy should also include considerations – even if they’re not specifically names – for children, pets, bystanders, visitors to the home, accidental spills, etc. It’s not that those things are inherently bad, but they pose risks to corporate and customer information and equipment.

NOTE: I’m acutely aware of the sense that those not in infosec tend to see those in IT and Security roles as experimenters and gearheads who only think of people as users, weaknesses, statistics, and other non-human aspects. Much of that is the habit of those ITSec folks to bring the language of tech (users, roles, risks, vulns, authn/authz, access control, etc.) into the realm of humanity. While policies often require generic or technical language, don’t let that spill over into your interactions with others. They are people, not policies and procedures.

People as the Primary Attack Surface

When it comes to cybersecurity, technology often receives the spotlight - firewalls, encryption, and intrusion detection systems all play starring roles. Yet in reality, people remain the most frequently targeted component of any security environment. Attackers know this well. Phishing, social engineering, and misuse of access continue to outperform exploit kits and zero-day vulnerabilities because people can be persuaded where software cannot. (Note: this is because people care and want to be helpful, unlike software. This is NOT because people are “the weakest link.” Let’s give people proper credit.)

Information security policies that address human behavior must treat employees not as weak links, but as critical defenders. The goal is not to eliminate human risk, but to manage it through clear expectations, knowledge, and culture. The Acceptable Use Policy (AUP) becomes a foundational layer in this effort. It defines what constitutes responsible system use and outlines the boundaries that protect both data and users.

At its core, the AUP states that organizational systems and data are for authorized business use only. Employees are custodians of the company’s digital - and even physical - environment, expected to handle information and technology in alignment with established policies. That means things like refraining from downloading unauthorized software, connecting to the network with unauthorized gear, exfiltrating data, and attempting to bypass security controls. These aren’t arbitrary restrictions - they’re practical safeguards against both internal mistakes and external threats.

Because businesses are in the business of protecting customer data, using a corporate computer is not like being on a home computer for personal use.

Setting Expectations Without Over-Policing

A well-crafted AUP shouldn’t read like a list of punishments; it should set clear expectations while permitting people to make smart decisions. (although, ironically enough, the list is primarily "here's what is UNACCEPTABLE" instead of what's acceptable). Overly rigid language can create fear or confusion, leading to either apathy or deliberate workarounds. An employee who disables a security control because a system blocks legitimate work isn’t being malicious (well, not always – beware) - they’re trying to be productive, perceiving that their need for productivity is more important than the friction caused by controls. That tells us policy enforcement should blend accountability with compassion.

Leaders can foster this balance by emphasizing why the policy exists. When staff understand that each safeguard protects customer trust, intellectual property, and even their own reputations, compliance becomes an act of shared responsibility. This cultural framing turns “rules to follow” into “safeguards we all benefit from.”

In practical terms, managers should reinforce that acceptable use extends beyond the brick-and-mortar office. The modern workplace is fluid - remote work, mobile devices, and cloud collaboration all expand the security perimeter. Employees working off-site must – as appropriate to their org’s resources:

• Use only approved, managed devices
• Connect through secure networks (VPNs or trusted Wi-Fi)
• Ensure business data isn’t accessible to unauthorized individuals.

No company is the same, and not all companies can provide the best protection available in the world. The main infosec approach is to do the absolute best you can to make device and data security feasible – and much of that “best” is people doing their best, both in creating the controls and creating the proper environment for people to understand the purpose of the controls.

Simple lapses - e.g., allowing strangers to shoulder surf, discussing sensitive information in shared spaces - can have the same impact as major breaches. Clear expectations, reinforced through relatable examples, reduce the likelihood of such incidents without creating undue friction.

Training as a Control instead of a Checkbox

Security awareness training often suffers from poor framing. Too many organizations treat it as a compliance requirement - a box to tick during onboarding or annual reviews. That approach misses the real purpose: to equip staff with actionable insight they can actually use.

Training should be viewed as a control measure just like multi-factor authentication or an access log. It directly reduces human error and strengthens resilience against common attacks. Effective programs share several traits:

Timely delivery: Training must occur at key moments — during onboarding, before role transitions, and annually for reinforcement.

Interactive learning: Scenario-based modules and phishing simulations help people apply theory to practice.

Real feedback: Employees benefit when simulations provide clear explanations of what went wrong, not just pass/fail scores.

Leadership participation: When executives take part, it signals that security isn’t just an IT function; it’s a business priority.

Phishing simulations deserve special mention. They are not designed to catch employees off guard or shame mistakes but to raise situational awareness in safe conditions. Just as fire drills teach evacuation procedures, simulated phishing tests teach response habits: pausing before clicking, checking sender authenticity, and reporting suspicious messages.

Critically, organizations must frame these exercises as learning opportunities, not traps. Employees should feel empowered to ask questions and report close encounters without fear of reprisal. Always provide an easily accessible channel for communicating. Building this trust transforms training from an obligation into an ongoing dialogue.

Bringing It All Together

The convergence of human behavior, policy, and culture defines an organization’s security posture far more than any individual control. The Acceptable Use Policy and security training requirements provide structure, but it’s the united mindset that determines effectiveness.

By acknowledging human risk as the central attack surface, policymakers can shift from reactive enforcement to practical engagement. Policies become meaningful when employees understand their “why.” Training becomes meaningful when it changes real-world decisions. Together, these efforts anchor a culture of responsible technology use rather than mere rule compliance.

The goal isn’t to regulate every keystroke, but to ensure that everyone recognizes their role in safeguarding the organization’s digital assets. A culture that prizes awareness and accountability, and builds trust, will always outperform one that relies solely on controls.

In an environment where every click matters, encouraging people to act securely is the most effective defense of all.

Stay vigilant and safe!

Resources

Therefore, here are several places where you can find numerous policy templates to learn, get ideas, investigate, and modify relevant ones as needed. Happy hunting!

https://heightscg.com/2025/11/14/information-security-policy-templates/

https://heimdalsecurity.com/blog/nist-cybersecurity-framework-policy-template-guide/

https://www.cisecurity.org/controls/policy-templates

https://github.com/HailBytes/security-policy-templates

(NOTE: This downloads the PDF right away) https://www.azed.gov/sites/default/files/2023/03/04.%20Template%20Security-Awareness-and-Training.pdf

(NOTE: This downloads the Microsoft Word file right away) https://community.trustcloud.ai/kbuPFACeFReXReB/uploads/2023/03/ISO-27001_2022-Information-Security-Management-System-ISMS-Policy-Template.docx

https://policy.arizona.edu/information-technology/information-security-awareness-training-policy

https://blueteamalpha.com/resources/security-awareness-training-policy-template/  

https://claude-plugins.dev/skills/@diegocconsolini/ClaudeSkillCollection/cybersecurity-policy-generator

https://www.sans.org/information-security-policy

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1300.pdf

https://github.com/PehanIn/ISO-27001-2022-Toolkit

https://github.com/simplerisk/templates

https://github.com/JupiterOne/security-policy-templates

Most paths into cybersecurity run through the same checkpoints. Certifications. Lab environments. CTF competitions. These things have real value, they build vocabulary, they build technique, they get people hired. But there's a ceiling on what they can teach, and that ceiling shows up quite quickly when someone sits down to ponder an actual real world investigative scenario.

Real investigations don't start with a clean scope document and a pre-configured VM. They start with noise. A username fragment. A timestamp that doesn't quite fit. A piece of infrastructure that routes somewhere it shouldn't. The work is to build a picture from partial information, to pull threads until something coherent emerges. That's analytical reasoning under uncertainty, and almost nothing in the standard certification and CTF pipeline specifically builds that muscle.

CTFs come closest, but the format has a structural problem, most of them are puzzle boxes. You're handed a file, a service, or a network segment, and the flag is hidden inside it. The challenge is technical extraction. What's usually missing is the investigative layer, the part where you don't know what you're looking for yet, where the relevant data isn't labeled, and where the path forward requires judgment, not just tooling.

This isn't a criticism of CTF organizers.

It's a constraint of the format. Building a challenge that genuinely simulates how analysts work, with messy, ambiguous, multi-source data, is hard.

Most platforms aren't built for it. Hashclue is my attempt to build for it.

An Intelligence Game Built Around Investigative Tradecraft

The concept behind Hashclue is simple on its face, cryptographic treasure hunts with cybersecurity DNA. But the design philosophy underneath it is more specific than that. The goal is to simulate investigative thinking, not just test technical knowledge. A Hashclue challenge is an environment, not a puzzle box.

Players enter a narrative context, encounter a set of information artifacts (documents, metadata, identifiers, patterns, noise), and have to reason their way toward a hidden answer. The answer is committed on-chain via SHA-256 hash before the challenge goes live. Nobody can retroactively move the goalposts.

The techniques required are the ones that show up in real analyst workflows, OSINT, digital forensics, pattern recognition, cross-source correlation, geolocation, metadata analysis. Not as isolated modules, but woven together in the way an actual investigation requires. You might find a partial username in one place and need to connect it to infrastructure data somewhere else. The challenge isn't "find the thing in the file." It's "figure out what you're even looking for."

The tradecraft framing matters because it changes what success looks like. In a standard CTF, you either get the flag or you don't. In an investigation style challenge, the process is the point. How you reasoned through it, what you prioritized, where you got stuck, those are the reps that make analysts better.

What Is Hashclue?

Hashclue is a protocol and a game engine for building verifiable investigative challenges. The architecture is designed so that challenge answers are cryptographically committed before the challenge launches, players can independently verify that the answer hasn't changed and that solving it is possible.

This isn't just housekeeping. It's the foundation of trust that makes competitive play fair and makes Hashclue usable for serious training contexts.

The first Hashclue treasure is live. A physical cache is hidden. The path to finding it runs through a chain of digital clues, OSINT based, forensics adjacent, requiring both analytical reasoning and real world spatial thinking. The canonical secret string that unlocks the location is locked in publicly verifiable hash commitments.

Nobody can change where the treasure is. Nobody can fake solving it.

The challenge is designed to be hard. Not artificially hard, legitimately hard, in the way that real intelligence problems are hard. The answer requires synthesizing information from multiple sources and making judgment calls under uncertainty.

What the First Game Looks Like

The MVP challenge is a multi-stage investigation. Each stage produces an output that feeds the next. Players start with publicly accessible information and use a combination of OSINT techniques, metadata analysis, and forensic reasoning to progress through the chain. The terminal stage has a physical dimension, the final clue resolves to a real location where a physical object is hidden.

The location anchor is encoded in the canonical secret string, enough specificity to be unambiguous when you're standing in the right place, enough ambiguity that you can't brute force it from a map.

The challenge is open to anyone.

There's no registration wall, no entry fee, no time limit. If you can solve it, you solve it. The cryptographic commitment means verification is instant and trustless, either you have the canonical string or you don't.

This format is deliberately minimal for the first release. The design goal was to prove the model works before layering on complexity. Future iterations will support team play, multi-track difficulty, and integration with training programs.

An Invitation to the Cybersecurity Community

Hashclue is being built in public and the community can shape what it becomes. If you're an analyst, researcher, or practitioner, play the challenge. Not necessarily to win it, to pressure test the format. Does it feel like real investigative work? Where does it hold up and where does it fall short? That feedback matters to us early on.

If you build training programs, run a CTF, or work in security education the underlying protocol is designed to be extensible. The same cryptographic commitment structure that powers the first challenge can anchor corporate red team exercises, structured analyst training, or competitive events with real stakes.

If you want to explore what that looks like, get in touch.

If you work in threat intelligence, OSINT, or digital forensics the design process for Hashclue challenges is a research exercise in and of itself. Building a problem that's solvable but nontrivial requires thinking carefully about what real investigative paths look like. Collaborators who want to contribute challenge design, particularly people who work with these techniques professionally, are the most valuable thing the Hashclue Labs project can attract right now.

The cybersecurity community has always been better at building things collaboratively than any individual or company could build alone. Hashclue is a small idea that could become a useful part of the training ecosystem if the right people engage with it seriously. The first step is the challenge itself.

Hashclue is a cryptographic investigative game protocol. The first public challenge is live. Learn more at Hashclue.com.

Part 1 of a series on creating information security policies

Contents

• Security Starts at the Top (or, Governance Makes or Breaks Your Security Program)
• Disclaimer
• Why Governance Comes First
• The Information Security Policy: Setting the Tone
• Risk Management: Replace Guesswork with Discipline
• Roles and Responsibilities: Eliminating the Accountability Gap
• What Auditors Look For
• Common Pitfalls to Avoid
• Governance as a Force Multiplier
• Afterword about Infosec Policy and Infosec Policies
• Resources

Security Starts at the Top (or, Governance Makes or Breaks Your Security Program)

Security programs shouldn’t be tied to a specific tool or control. They need someone to own the risk. Firewalls expire, policies gather dust, controls erode, not because of maliciousness or incompetence, but because governance was either not firmly established, or because it lost accountability.

ISO 27001 and SOC 2 both recognize this reality. They differ in structure and emphasis, but both begin with the same foundational assumption: information security is a management responsibility before it is a technical one. Governance sets direction, establishes accountability, and ensures that security decisions are made deliberately rather than reactively.

This first month focuses on the policies that anchor the entire security program: information security governance, risk management, and clearly defined roles and responsibilities. Without these, every other policy becomes harder to justify, harder to enforce, harder to defend.

Disclaimer

Hear ye, hear ye! Be it known unto all who peruseth this lowly scrivening that this author, though steeped in the arts of information security, is neither auditor, attorney, barrister, counselor, nor any other sworn keeper of royal law. These words are penned in good faith and offered for enlightenment and mirth, not as binding decree nor legal writ.

Shouldst thou require counsel of a lawful, legal, legitimate, licit, sanctioned or otherwise authoritative nature, get thee hence with all due speed to a licensed solicitor or other learned scribe of relevant and pertinent statutes. For, verily, the author claimeth none liability shouldst thine compliance dragons awaken or thine auditors grow discontent.

Why Governance Comes First

Governance answers three questions every auditor and executive will eventually ask:

1. Who is responsible for information security?
2. How does the organization decide what risks are acceptable?
3. How do security decisions support business objectives?

Organizations that can’t answer these questions will drift into one of two paths toward failure.

Path 1: Overly restrictive, deploying controls that frustrate users without meaningfully reducing risk (this is moving beyond friction to inefficiency).

Path 2: Permissive to the point of negligence, accepting risks simply because no one took ownership to decide otherwise.

A governance-driven security program avoids both extreme roads by making risk visible, intentional, and owned – particularly to the proper stakeholders.

The Information Security Policy: Setting the Tone

The Information Security Policy is often dismissed as a formality - it’s a document written once, approved once, and rarely revisited. It’s actually THE SINGLE MOST IMPORTANT policy in the entire ISMS (Information Security Management System).

This policy establishes:
- The organization’s commitment to protecting information
- The objectives of the security program
- The scope of systems, data, and personnel covered
- Management’s authority to enforce security requirements

For ISO 27001, this policy formally defines the scope of the ISMS. For SOC 2, it demonstrates that management has acknowledged responsibility for meeting the Trust Services Criteria.

A note on SOC 2: there are 5 “Trust Services Criteria,” only 1 of which is required (some reviewers can be confused about the flexibility), though more are always a better sign of your security posture to prospects.
More details here: https://cloudsecurityalliance.org/blog/2023/10/05/the-5-soc-2-trust-services-criteria-explained

A strong Information Security Policy avoids technical details. Instead, it speaks in the language of leadership.  

NOTE: There’s a difference between policies, procedures, guidelines, and standards. Most of what SMBs, especially unregulated ones, will use are Policies and Procedures. Here’s a good summary: https://www.dummies.com/article/academics-the-arts/study-skills-test-prep/cissp/develop-implement-documented-security-policies-standards-procedures-guidelines-225446/

The main Infosec policy communicates intent, not implementation.

Firewalls, encryption, and monitoring are addressed elsewhere; this policy explains:

why the controls exist, and
who stands behind them.

When auditors review this policy, they’re not looking for perfection (though they will have specific items they have to see, e.g., they’ll demand a Version Table). They’re not looking for specific tools, technologies, or titles. They want to see evidence that leadership understands its role and has set a clear direction for the organization. While it needs to be reviewed at least annually, design it so that it doesn’t need to be changed much, but make it easy to change if needed.

Risk Management: Replace Guesswork with Discipline

Risk management is the connective tissue between the muscles of governance and control implementation. Without it, security decisions are driven by fear, headlines, or vendor influence. With it, decisions become consistent, explainable, and defensible.

A Risk Management or Risk Assessment Policy defines how the organization:
- Identifies risks to information assets
- Analyzes likelihood and impact
- Determines acceptable risk levels
- Selects risk treatment options
- Reviews risks over time

ISO 27001 is explicit in its requirement for a risk-based approach. Controls are not implemented because they appear in some standard somewhere, but because they mitigate identified risks. SOC 2, while less prescriptive, still expects organizations to demonstrate that risks have been identified and addressed through controls.

Risk management does not require mathematical precision (though there are approaches such as FAIR, that rely heavily on mathematical calculations). Auditors expect consistency - assess risks using the same criteria each time, document them in the same way, and review at a defined cadence (often it's expected to be at least annually).

Equally important is ownership. Every significant risk must have a named risk owner - someone accountable for accepting, mitigating, transferring, or avoiding that risk. When risk ownership is absent, risk acceptance becomes accidental instead of intentional.

Roles and Responsibilities: Eliminating the Accountability Gap

A common audit finding across both ISO 27001 and SOC 2 is unclear responsibility. Tasks are performed and decisions are made;, but ownership is vague and authority is implied rather than documented.

A governance policy needs to clearly define:
- Sponsorship from executive leadership for the security program
- Responsibility for maintaining policies
- Authority to approve exceptions and accept risk
- Accountability for system and data ownership

This doesn’t require a large security team, btw. In smaller organizations, individuals often hold multiple roles (a lot of responsibility can be crammed in Security Manager). What matters isn’t separation, but clarity. Auditors want to see that someone has both the authority and responsibility to make security decisions.

Clearly defined roles also reduce friction internally (friction can be good when it puts the brakes on to keep from crashing, but too much and it moves beyond irritating to become detrimental). With documented expectations, security stops being perceived as arbitrary and starts to be predictable and fair.

What Auditors Look For

When auditors assess governance, they’re looking for alignment, not volume. A small, well-integrated set of documents is often more effective than an extensive library of disconnected policies.

Auditors look for:
- Management approval of the Information Security Policy
- Evidence that risk assessments are performed and updated
- Clear assignment of responsibilities
- Consistency between governance documents and operational controls

Perhaps most importantly, auditors look for intent. Controls should exist because risks were identified. Relevant risks should be accepted because leadership understands the implications, not because they want to avoid hassle. Nothing should exist simply because “the framework said so.” Having said that, some regulated industries have rigorous frameworks that already outline what needs to be done. So “the framework said so” is a requisite starting point, and those mandatory controls really do have to be in place – take them seriously, and as needed, go beyond to ensure proper data security. But also, in the spirit of “reasonable security,” don’t take them further than they need to be taken – no sense spending $1 million to protect only $500K of assets. Some examples of rigorous particulars are NIST, HIPAA, HITECH, HITRUST, and PCI-DSS.

Common Pitfalls to Avoid

Organizations can easily undermine governance unintentionally. Common mistakes include:

·       Treating the Information Security Policy as a boilerplate document

·       Performing risk assessments once and never revisiting them

·       Allowing risk acceptance without executive awareness

·       Failing to document who owns which decisions

Here’s how to overcome these Pitfalls:

·       Make it your own! After having written policies several times in a few organizations, I’ve noticed that it’s difficult whether you create a new policy from scratch, or rewrite existing policies. Lean on your own preference – do you like to create written documents anew? Or do you like to rewrite? The only proper thing to do is to Get. It. Done. But, once you’re done, it’s easy to update.

·       Risk assessment needs to be annual – put it in your calendar with ample reminders. Make it an annual meeting with other involved – and let them know if they can’t make it, they need to send someone as a delegate. No exceptions – consider it a baseline or foundation.

·       Even in small orgs, email it to all involved or affected (aka, stakeholders). You can even say, “If there are no changes by XYZ date, I’ll take that as acceptance.” That way, you don’t have to follow up with everyone.

·       Don’t just write someone’s name down and leave it. They need to be reminded, and that falls to the ISMS lead. Others have many other responsibilities, and it’s easy for them to forget about this and/or let this go. This is where Project Management skills come into play. Take the lead to put it on their calendar, or remind yourself to email them a reminder, about a time to renew and review. Make it part of the org direction, not just a single person’s idea, and that will help get (though not guarantee) agreement on the teamwork.

These gaps don’t necessarily cause immediate problems, but they always surface during audits. Or – regrettably - after a breach, when decisions must be explained under scrutiny. One of the worst things to have to say on the stand is, “We weren’t aware of those risks.”

Governance as a Force Multiplier

Strong governance does more than satisfy auditors. It simplifies every other policy that follows. When objectives are clear and risk tolerance is defined, access control decisions become easier. Incident response becomes more decisive. Vendor risk discussions become more productive.

In many ways, governance is a force multiplier. It allows smaller teams to operate effectively and larger teams to stay aligned. It transforms security from a reactive function into a managed program.

As this series continues, each subsequent policy builds on the foundation established here. Without governance, controls exist in isolation. With governance, they become part of a coherent system.

Afterword about Infosec Policy and Infosec Policies

This primary Infosec Policy can be confused with the Infosec policies. Yes, it’s weird. Some places will ask for your information security policy AND your information security policies. Well, which is it? Here’s an explainer if you’re stuck.

The Information Security Policy is just as described in this article - it’s the overarching source, the foundation, of all-things-infosec.

The infosec policies (plural) are all the other policies involved – access control, backup/restore, physical security, password management, etc.

There’s no way around it: for a good ISMS, you’re going to have numerous policies. A distractor is that policies are often thought of in the way they used to be many years ago – cumbersome, full of irrelevant legalese, written for the erudite and not the common person.

Policies have changed. Yes, they still have to have certain legal wording in them; yes, there have to be several; yes, they have to be updated, documented, and readily available. However, they don’t have to be as long as some may think. To rephrase a saying, this isn’t your grandad’s infosec policy.

SMBs often have a choice in how they work on their entire policy book – an all-in-one (AIO) document, or all separate. If AIO, then it’s just one long document that people have to read and acknowledge. But it’s long and can be tedious to navigate.

If separate, then they’re easier to update, not having to scroll, scroll, scroll. But it can be annoying to have to open 12 separate policies.

But the org gets to decide. There’s no right or wrong, except if you don’t have them.

What’s your next step? If you’re stuck, maybe the resources below will help you along. Do the next thing, and the next thing will follow.

Happy Governing!

Resources

SANS: https://www.sans.org/information-security-policy

Heimdal Security: https://heimdalsecurity.com/blog/information-security-policy-template/

Purplesec: https://purplesec.us/resources/it-security-policy/

Rocket Lawyer: https://www.rocketlawyer.com/business-and-contracts/employers-and-hr/company-policies/document/information-security-policy

Kordon: https://kordon.app/information-security-policy-template-free-download/

Cynomi: https://cynomi.com/blog/the-essential-information-security-policy-template/

FRSecure: https://frsecure.com/information-security-policy-template/

Hyperproof: https://hyperproof.io/resource/information-security-policy/

Contents

1. The Ethical Blueprint: Building Trust in Synthetic Media
   1. S - Social Benefit
   2. C - Consent
   3. A - Accountability
   4. N - Non-Deception
   5. T - Transparency
2. Putting SCANT into Practice
3. TL;DR Checklist
4. It takes work!
5. AI - Embracing the Human
6. Speaking of ISO 42001

The Ethical Blueprint: Building Trust in Synthetic Media

Lots of damage has been done with AI, and to keep from deep-sixing the forward-leaning tone I want in this article, I’ll refrain from noting any details – the internet is available for you to search to your heart’s content. I want to start with that note because how we use AI is not just an option, like whether we want a cinnamon roll or a bagel at breakfast. AI use has meaning – whether it’s dark or not depends on each of us.

On the lighter side of negative consequences, more and more media influencers are posting AI videos claiming that those videos aren’t AI, just to increase their views and to increase interaction – drawing out those who claim, rightly, that the media truly is AI, and then arguing back and forth about its validity. Some influencers are abusing AI to waste peoples’ time for the sole benefit of the influencer; and those actions a) further erode viewers’ trust in media platforms and b) turn them against the hope of the real usefulness of AI. (plus, it wastes their time, and that time is part of life, so it really grinds on the nerves to realize that one has spent some of their life’s breath only to be been taken for a fool). So, even on the lighter side, those consequences are eroding trust in all-things-online. But with running with the concept of “learn to discern,” one can beat that fraud. Mitch Clark does an excellent job at educating on this.

For a recent cybersecurity presentation, I worked with the bots to create an ethical AI framework to fit GenAI in general. The bots gave me some decent ideas, and I prompted back and forth with them, and then moved it into my own short set that I then made into an acronym. Mnemonic devices to the rescue! This is also an example of human-in-the-loop in AI – the robot gives some information, and there’s back-and-forth between me and the machines, but in the end it’s human creativity and alignment of the information presented that wins the day.

Are there other frameworks? Sure! Well-researched ones, official governmental ones, professional community-developed ones. But I wanted to make one that’s maybe more accessible to the general public. Will it fail to gain traction? Certainly! But I have today, and maybe someone will read this and either learn something, or think “I can do better” and I will have accomplished a goal of forcing others to write better things because I wrote a so-so thing. (I do this at home – I throw out weird, and even bad ideas, and that forces the kids to create better ideas 😊 )

SCANT is a concise and actionable set of principles designed to keep AI-generated media safe, respectful, and trustworthy.

Why SCANT? Scant means “falling short of what is normal, necessary, or desirable.” I decided to keep it because it’s an insufficient approach, but may be simple enough to either work as-is or urge others on to make their own. AI is still a nascent field, and a good improvement would be for those involved in the field to either adopt or form their own workable models for evaluating how AI is developed in their org, even if it’s nothing fancy.

Yes, of course there’s ISO 42001 ! There are great things happening around the world. Those can be expensive and cumbersome, though just knowing the principles and proceeding accordingly is a great way to show others how you align your AI practices with the international standard. SCANT is simply a “pet project,” if you will, so I thought I’d bring it in the open.

NOTE: The term “deepfake” is often used to describe unethical use of high-quality GenAI, but the term is actually used for any of those high quality results. Throughout this article, deepfake is used for the final product, not simply for the deceptive kind.

SCANT

S - Social Benefit

The Goal? Deploy deepfake technology only when it creates a positive impact for individuals, communities, or society at large.

C - Consent

Goal: Secure explicit and informed permission from every person whose likeness, voice, or mannerisms are used.
(Are voice trademarks the path forward? See this article re: Matthew McConaughey trademarking his voice https://analystip.com/matthew-mcconaughey-trademark-himself-to-stop-ai-clones/ )

A - Accountability

Goal: Ensure that creators, distributors, and platform operators can be identified, held responsible, and answerable for the consequences of synthetic media.

N - Non‑Deception

Goal: Prevent the intentional misleading of viewers; synthetic media should be used to educate, entertain, or augment reality - not to fabricate false narratives.

T - Transparency

Goal: Make it unmistakably clear that a piece of media is synthetically generated; and disclose the technical provenance behind it.

Putting SCANT into Practice - a mini-workflow

1. Idea Generation
   • Conduct a Social Benefit questionnaire
   • Draft a Purpose Statement and identify target audiences
2. Consent Acquisition
   • Send a consent package (explanation + digital signature)
   • Store signed consent with timestamped metadata
3. Model Selection & Documentation
   • Choose an AI model, note version, training data, and any fine‑tuning.
   • Log all generation parameters in a tamper‑evident ledger
4. Creation & Attribution
   • Generate the deepfake, embed provenance metadata, and apply a visual Transparency watermark
   • Record the creator’s identity and any human post‑processing
5. Review & Accountability Check
   • Submit the asset to the internal Ethics Board for Non‑Deception and Social Benefit validation
   • Verify that Consent and Transparency requirements are satisfied
6. Publication
   • Release the content on chosen platforms with clear labeling (e.g., “Synthetic Media – For Educational Purposes”)
   • Provide a public link to the provenance record
7. Post‑Release Monitoring
   • Track audience reactions, complaints, or misuse reports
   • If a violation is detected, invoke the Accountability remediation plan (removal, apology, compensation)

TL;DR Checklist

• Social Benefit: Purpose‑first, impact‑focused, measurable outcomes.
• Consent: Informed, freely given, specific, revocable, verified.
• Accountability: Provenance metadata, governance board, liability clauses, audit logs, remediation pathways.
• Non‑Deception: Intent clarity, no covert splicing, preserve factual context, educate viewers.
• Transparency: Persistent synthetic label, model/version disclosure, generation parameters, human‑oversight note, public provenance API, visual watermark.

Embedding these SCANT principles into every stage of the GenAI lifecycle - from conception to post‑release monitoring - creates a defensible (yes - you'll need to defend it to customers and/or auditors) and ethically sound workflow that respects individuals, protects public discourse, and unlocks the creative and societal potential of synthetic media.

How does the typical person use this? It’s really easy, actually (at least, it should be). Don’t be a jerk, don’t steal, don’t defraud, don’t mislead. Those bad things have been going on for a long time. Anyone on any social media has seen or taken part in news by memes, spreading mis/dis/mal information simply by passing on something revealing or shocking based only on a well-crafted meme, which probably has authority based on who shared it, but itself has no link, source, time/date stamp, or anything that remotely resembles a way to verify. Don't be part of that "game" - help out viewers and readers.

Humor, comedy, and satire are part of freedom of speech, so it's vital that we remain ethical in synthetic media while NOT stamping out these freedoms.

It takes work!

You may notice that this is a lot of work. It should be. The capabilities of AI can’t be taken lightly. Lives and reputations have been harmed because of the focus on Speed over Stability. While much of the software world has been driven by, “Hey, let’s create something simple and then build on it after we get feedback,” so much of AI has been, “Let’s throw this enormous thing out that, see what happens, and then pare back from there.”

Whatever approach is taken, the work needs to be put in to make AI a proper tool for everyone who wants to use it.

AI - Embracing the Human

AI is powerful. Proceed cautiously. Any reputable AI offering will use cautionary words similar to, “Do not rely on AI’s results for critical business or personal decisions.” Everyone knows that AI can be wrong…or do they? (think of the movie, "I, Robot")

AI does not have intellect or will – it has no soul. It’s complicated, hi-tech, seemingly magical and mystical, but behind it all is a robot, a bunch of machines.

Harvard has an AI for Human Flourishing program, so that’s a good way to get insight into in-depth studies already performed on the potential full useful aim of AI.

An AI benchmark in conjunction with this program is the Flourishing AI Benchmark (FAI Benchmark). The benchmark is described as follows:

“…a novel benchmarking approach that evaluates LLMs across seven key dimensions of human flourishing, based on the flourishing measure developed by researchers at the Human Flourishing Program at Harvard and in collaboration with Barna and Gloo:

1. Character and Virtue (Character)

2. Close Social Relationships (Relationships)

3. Happiness and Life Satisfaction (Happiness)

4. Meaning and Purpose (Meaning)

5. Mental and Physical Health (Health)

6. Financial and Material Stability (Finances)

7. Faith and Spirituality (Faith)”

A name connected to the study is Pat Gelsinger, a name you may recognize from his times as CEO of VMWare and Intel. More information here: https://techcrunch.com/2025/07/10/former-intel-ceo-launches-a-benchmark-to-measure-ai-alignment/

From their report: “Initial testing of 28 leading language models reveals that while some models approach holistic alignment (with the highest-scoring models achieving 72/100), none are acceptably aligned across all dimensions, particularly in Faith and Spirituality, Character and Virtue, and Meaning and Purpose.”

Don’t expect AI to speak realistically to matters pertaining to the above deficient areas. Regrettably, many have been severely and negatively affected by expecting their LLM(s) to provide precisely these kinds of ethical and life guidance.

In general, current models have the goal of helping people while not causing harm, but some important areas have been overlooked. With such powerful implications, while AI has not considered people holistically, it could be developed to take the whole person into account.

 Speaking of ISO 42001

ISO 42001 is considered THE international standard and governance framework for AI. To align with ISO 42001 principles, here’s a high-level plausible mapping (focus on plausible - nothing official here).

I've been dealing with data privacy regulations for over 15 years. GDPR, CCPA, dozens of state laws—most of them great on paper, terrible in execution. But California just launched something different.

It's called DROP (Delete Records Of Personal Data), and it's the first government-run platform that lets you nuke your data from 1,600+ data brokers with a single request. No forms per broker. No endless verification emails. One click.

Sounds too good to be true, right? Let me tell you what's actually happening under the hood.

The Problem DROP Actually Solves

Here's what data deletion looked like before DROP:

• You discover Acxiom has your data.
• You submit a deletion request.
• They have 45 days to respond.
• You verify your identity in three different ways.
• They finally delete it.
• Meanwhile, 83 other brokers still have it.

Want to clean them all? That's 84 separate requests, 84 verification processes, months of follow-up. Nobody does it. That's exactly why the system was broken.

The DELETE Act (AB 375) changed the game. Instead of putting the burden on consumers, it created a centralized deletion mechanism. And DROP is that mechanism.

How DROP Actually Works (Technical Reality)

When you submit a request through DROP, here's what happens:

• Identity Verification: California uses Login.gov for authentication. This isn't just username/password—it's identity proofing that meets NIST 800-63-3 standards. They need to know you're actually you before they start deleting your data everywhere.
• Broker Notification: Your deletion request hits the California Privacy Protection Agency's system. They batch requests and distribute them to registered data brokers through their Data Broker Registry.
• 48-Hour Window: Brokers have 48 hours to acknowledge receipt. Not 45 days to complete it—48 hours just to say "we got it."
• Verification Requirements: Here's where it gets interesting. Each broker has to verify it's actually your data before deletion. But they can't ask you to verify each request individually (that would defeat the purpose). So they're stuck implementing automated verification systems that work with DROP's authentication.
• Deletion Execution: Brokers must delete data from:
  • Active databases
  • Backup systems (this is the hard part)
  • Derived datasets
  • Third-party systems where they've shared your data

That last one is brutal. If Broker A sold your data to Broker B, Broker A has to track down Broker B and get them to delete it, too.

The Security Nightmare Nobody's Talking About

DROP is brilliant from a consumer perspective. From a security perspective, it's terrifying. Here's why:

• Mass Deletion Authority: Think about what DROP represents—a single authentication that can delete data across 1,600+ organizations. That's an incredibly high-value target.
• Identity Theft Paradise: If someone compromises your Login.gov account, they can delete your data from every broker. Sounds good until you realize some of that data is used for fraud prevention. Suddenly, you can't open bank accounts, get credit, or verify your identity anywhere.
• Broker Authentication Gaps: Each broker needs to verify that the deletion request came from DROP and applies to real data. Most brokers aren't equipped for this. They're going to implement whatever's easiest, which means inconsistent security across the ecosystem.
• No Audit Trail for Users: You submit a request. You get confirmation that it was sent. But do you know which brokers actually deleted your data? Do you know what they deleted? Do you know if they missed anything in backup systems? Nope.

What Data Brokers Are Actually Doing

I've talked to folks at several data brokers. Here's what's happening behind the scenes:

• Some are building compliant systems. Automated verification, proper deletion workflows, and audit logs. It's expensive and time-consuming, but they're doing it right.
• Others are taking shortcuts. "Soft deletes" where data gets flagged but not actually removed. Automated "we can't verify this" responses to slow things down. Creative interpretations of what counts as "derived data."
• And some are just confused. They don't have systems to track where they've shared data. They can't identify all instances of a person's information. They're going to miss stuff—not maliciously, just because their infrastructure can't handle it.

The CCPA Compliance Trap

Here's the part that keeps me up at night: DROP is built on CCPA's deletion requirements. But CCPA has exceptions—lots of them.

Brokers can keep your data if they need it for:

• Completing transactions
• Detecting security incidents
• Complying with other legal obligations
• Internal uses "reasonably aligned" with consumer expectations

That last one is a loophole big enough to drive a truck through.

So you use DROP, you get confirmation, you think you're clean. But Broker X kept 40% of your data under "reasonable business purposes." You'd never know unless you submitted a CCPA data request separately to see what they still have.

What Actually Needs to Happen

DROP is a good start, but here's what would make it actually work:

• Verification Transparency: Users need to see which brokers confirmed deletion and which ones claimed exceptions. Right now, it's a black box.
• Automated Monitoring: The system should periodically check if deleted data reappears. If Broker A deleted your data but Broker B (who bought it from A six months ago) still has it, you should know.
• Penalty Enforcement: CCPA violations can cost $7,500 per violation. But unless California actively audits brokers, there are no teeth. They need automated compliance checking, not an honor system.
• Data Minimization Standards: Instead of just enabling deletion, require brokers to justify why they're collecting data in the first place. Make them prove the business purpose before collection, not after.
• Kill Switch Limits: Right now, DROP can delete everything. There should be categories—delete marketing data but preserve fraud prevention data, for example.

For Security Practitioners

If you're working on systems that might interact with DROP (or similar platforms that will inevitably follow), here's what you need to think about:

1. Identity verification chains: How do you verify a deletion request is legitimate when it comes through an intermediary platform?
2. Data lineage: Can you actually track where you've shared data? If California says delete, can you find all copies?
3. Backup system integration: Your backup retention policy just became a compliance risk. Can you selectively delete from backups?
4. Audit logs: You need tamper-proof records of what was deleted, when, and why. This will matter when regulators come asking.
5. Fraud implications: What happens when someone deletes their data and then claims they never had an account? How do you prove anything?

The Bigger Picture

DROP is California's move. But it won't be the last. Europe's looking at similar centralized mechanisms. Other states will follow.

Within two years, we'll probably see a national version (or at least regional platforms that interoperate). That means identity systems need to be built for this from the ground up.

The companies that figure out privacy-preserving identity now—where users can prove who they are without sharing unnecessary data, where deletion is clean and complete, where transparency is built in—they're going to have a massive advantage.

The ones still treating data like it's 2010? They're going to spend the next decade in compliance hell.

About the Author

Deepak Gupta founded and scaled a CIAM platform to serve 1B+ users, dealing with identity and privacy regulations globally. He's now building AI-powered solutions at GrackerAI and LogicBalls. More at guptadeepak.com.

Happy New Year! Many have made plans, goals, and resolutions for 2026 – diet, exercise, business, and finance are just some of the determinations to make personal and professional changes.

While the categories are common, how each of those plays out is completely individual. How one goes about losing weight or getting fit; how much money to save or how much debt to pay off; what certifications need to be made or university classes to take – it all depends on what you want to do, where you want to go, who you are, and who you want to be.

When reviewing vendors, there are almost just as many factors. Are you in a regulated industry? What kind of data do you hold? What’s the maturity of the vendor review process? Public or Private sector? How much revenue is available? What role and risk classification do the potential vendors play in the org? There’s no one-size-fits-all for the vendors, and, therefore, no way to present a single approach to solve the Gordian knot that is third-party management.

However, knowing more about what’s involved can help create a better approach than one had before learning more.

This is NOT a best-practice guide, but I hope the following ideas will help you as you create an AI vendor vetting strategy appropriate to your company.

And just like New Year’s resolutions, having your “Why?” in place is important. Proper vetting of AI vendors better protects your corporate and customer data and reputations. Not protecting these personal, private, and proprietary details could easily land an organization in legal and regulatory hot water, incurring high fines and legal fees.

Disclaimer: I’m not employed by anyone I mention below, nor do I receive any kind of kickbacks, incentives, etc. There are no sponsored links or anything of the kind. Everything I link to is just to provide information.

Main Questions

In short, the main information to get from the vendor includes:

·        Where is the data is going?

o   What and where are the subprocessors?

·        Do they train anything on your data?

o   Many AI vendors train on your data depending on the pricing model. It’s “privacy at a price,” but at least they’re transparent about it (often only in the fine print, unfortunately).

·        What is done to secure the data?

·        What protections are in place for cross-border transfers?

o   Even if it’s transferring just username and email, that could be enough to warrant a DPA (Data Protection Agreement/Addendum) or SCC (Standard Contractual Clause).

An aspect that complicates what matters is that the information, if available, can be anywhere on the vendor’s site. A security statement, the Privacy Policy, DPA, Terms of Service, T7Cs (Terms and Conditions), MSA (Master Subscription Agreement), GDPR/CCPA/CPRA notice, Trust Center. It’s fine that every company has its own site layout - it just makes it tougher when reviewing and assessing when the site designers don’t have security review in mind. Be prepared for a trip on the ethereal highway. There have been several vendors where it was faster to go to ChatGPT or Perplexity and ask “Does ABC have a Trust Center?” and it gives me the URL much faster than it took me not to find it by going directly to the vendor.

Think also about those in your company, your internal customers, coworkers, and employees. What do you need them to tell you so you can make an appropriate review?

·        What is the application being used for?

o   Is it dev? Trial? Production? On your site or in your app?

·        How many people will use it?

o   One department only? Corporate-wide?

·        Would any customer data be involved?

·        Will corporate data be moved?

·        Is there another app already in use that would fulfill the function?

·        Is GenAI involved? If so, to what extent?

·        If there are multiple options, which option is under consideration?

Each organization has its own regulatory, compliance, security, and contractual needs, so apply the above and the following as you see fit.

Keep track of the requests! You don’t want to get caught up in any corporate spitting matches such as “why did you approve this?” Actually, you could easily be caught up in those, but the primary concern is having a good and documented approach and response.

You don’t want to have to vet the same vendor (believe me – there are more vendors than can be kept in memory, especially when they have similar names!). Sometimes, one department doesn’t know that another department already has it, so it could save on licensing, too (and saving money is always a plus for the business).

Have an AI AUP (Acceptable Use Policy) in place to point your company to as a constant reference. As often as possible, point to an authoritative internal source document; this will prevent lots of time with extra typing, lots of time in communicating, and prevent others from using you as the source of info each time.

If you want to get quite technical - both for questions for vendors and for answering your own customers’ questions - the AI questions in the HECVAT is an excellent resource for questions. As of this writing, it’s version 4.1.4. https://www.educause.edu/higher-education-community-vendor-assessment-toolkit

 For internal risk assessment - something you can use yourself or pass to your coworkers to fill out (though you may want to simplify it because of its complexity), this is an excellent spreadsheet from FS-ISAC here: https://www.fsisac.com/hubfs/Knowledge/AI/FSISAC_GenerativeAI-VendorEvaluation&QualitativeRiskAssessmentTool.xlsx

There are innumerable determining factors in what to look for when someone requests the use of AI in your company: How are you yourself going to use it? How will your other departments use it? Will it be used in a cloud instance? Or locally? Is it being tested for inclusion in your product? Or will it just be for educational purposes? What data is going in and through it? Does it need watermarked? Is your industry regulated? What will your customers expect from the product? In what industries do your customers live? These are just some of the options to consider (and we haven’t even touched on what resources you have to obtain, test, and maintain all-the-AI-things).

For many of the AI vendors I’ve reviewed, I’ve noticed a good number who have SOC 2 Type1 or 2, and ISO 27001. Before AI, many vendors didn’t have those. So, at least AI vendors are aware of that. But what’s strangely absent is available and solid documentation on their AI development process and internal AI use. While I’m not often expecting ISO 42001, I’m expecting at least “here’s a solid page about how we develop AI, how we address ethics, etc.” But, often, nothing is available, not even in the SDLC.

Have some idea of what you need from the potential vendor in the form of documentation, and this can be done with a simple matrix (again, this is just a sample, in the hopes that it gives a starting point for your consideration):  

Let’s get into the verbiage-laden details.

Considerations

All of these can be prepended with “as needed” or “where applicable” or “depending on your risk program” or other qualifiers. Keep that in mind when going through each – it’s not all required, and you may user different terminology.

Mapping the Data Landscape

Get a clear picture of where the data lives and moves. The vendor may be able to supply a Data Location Matrix that identifies the geographies, region, and cloud providers used for each data type - raw inputs, processed outputs, and logs. This matrix lets you verify that the storage locations align with your regulatory obligations (for example, there could be a requirement for “Acme Corp. needs EU‑West for GDPR‑covered data”).

This is often revealed in a simple Subprocessors list that shows who it is, where it’s located, and the purpose for data transfer. (hint: when you search, search for subprocessor and sub-processor - people spell things differently.)

Ask for a Data Flow Diagram (DFD) that traces the journey of information from ingestion through transformation, model inference, and any outbound transfers. This is more specific and visual than the Location Matrix. The diagram needs to expose every third‑party sub‑processor (analytics services, AI request processing, backup providers, hosts, storage) so you can confirm they are covered by the same Data Processing Agreement (DPA). If the flow involves cross‑border movement, the vendor should explain which approved mechanisms (Standard Contractual Clauses, Binding Corporate Rules, or adequacy decisions) are in place.

Again, they may only be able to supply subprocessors, and that’s generally fine; at least you know where the data goes. Also, they may not provide such detail and will only provide an overview – not to dodge the issue, but to protect details about their infra.

Understanding the privacy scope is essential. Customers need to classify the data it will handle - personal identifiers, health records, financial details, or proprietary business information - using your company’s data‑classification framework. Verify that the vendor follows the principles of purpose limitation and data minimization, collecting only what is strictly necessary for the AI service, and that a lawful basis or explicit consent is documented for each data category.

You may only get to see the Privacy Policy, perhaps even a DPA. Check both, plus anything like GDPR/CCPA/CPRA and other data privacy and security documents and statements. Make sure you print those and keep them.

Clarify retention and deletion policies. Define explicit retention periods for each class of data, and require the vendor to provide secure deletion methods (such as cryptographic erasure or physical shredding) on contract termination or upon your request. Auditable logs that prove deletion events should be part of the deliverables.

Legal and Contractual Safeguards

You probably need a Data Processing Agreement (DPA) if data travels anywhere other than just within the USA. Treat the DPA as a standalone annex that can be updated without renegotiating the entire contract. It must spell out the precise scope of processing, the security obligations the vendor assumes, a breach‑notification timeline of typically no more than 72 hours (some regulated companies may push for a quicker turnaround, so be ready to negotiate), and the process for approving any sub‑processors. Include clauses that obligate the vendor to assist with data‑subject rights (access, rectification, erasure) and that grant you audit rights. Liability caps should reflect the sensitivity of the data - typically at least the total contract value - and an indemnification provision should cover breaches caused by the vendor’s negligence.

The main point is to give contractual assurance that a customer’s data is transferred securely (meaning, “If you don’t protect our data, we’ll sue you big time”). There’s a misconception that under GDPR or other regulations that data can’t be transferred at all. That’s not the general idea; the general goals are that data transferred is a) transferred and handled properly, b) customers know as precisely as possible what data is transmitted, and c) customers know where it all goes.

This usually falls under the authority of someone who has contract signing authority, such as the Legal department or C-Suite function; it’s often beyond the scope of someone doing vendor management to sign. But the ones handling vendor management are in the middle and need to know the process.

Demand evidence of industry certifications that match your sector’s expectations. At a minimum, look for ISO 27001 (information‑security management) or SOC 2 Type II (service‑organization controls). Depending on the data you’ll be sharing, additional attestations such as ISO 27701 (privacy), PCI‑DSS (payment data), or a HIPAA Business Associate Agreement (health data) may be required. If your organization follows emerging AI‑specific frameworks - such as ISO 42001 for AI risk management - ask the vendor to demonstrate alignment.

Unless you absolutely have to, don’t combine “please provide your SOC 2 Type 2 report, ISO 27001 certificate, AND then answer these 300 questions that we could answer if we actually read the documents.” That greatly prolongs the pre-engagement phase of the procurement process. SOC 2 Type 2 and ISO 27001 - while not an ongoing assessment of vulnerabilities – when done by good auditors are rigorous assessments and attestations of the proper functioning of security controls and an infosec management system.

Minimum Security Measures

Not everyone is able to spend money on SOC2, ISO, or other standards. But there should be documentation available, even if it’s by being able to request it via a contact on the site. Because GenAI and other AI services are so new, many vendors are small in staff size, rather new to the business/security/vendor review game, and are focused on providing the services rather than having a full-service site. An encouraging trend I’ve noticed over the last few years is that vendors I re-review have an improved site, so there’s maturity in that area.

Security starts with encryption. There’s hardly anybody who doesn’t transfer data via HTTPS/TLS, but it helps to make sure (just search for data leak and breach occurrences due to lack of foundational security to reinforce the idea that one needs to cover the bases). All data at rest should be protected with AES‑256 or stronger algorithms, while data in motion must travel over TLS 1.2 or higher (TLS 1.3 is preferred). Keys should be managed by a dedicated hardware security module (HSM) or a reputable key‑management service such as AWS KMS or Azure Key Vault.

Vendors should implement strict identity and access management (IAM) based on the principle of least privilege. Every user and service account should receive only the permissions required for its function, and privileged access must be guarded by multi‑factor authentication. Regular access‑review cycles should be in place to prune stale privileges.

Security should be baked into the software development lifecycle (SDLC). Vendors should integrate static and/or dynamic application security testing (SAST/DAST) into continuous integration/continuous deployment (CI/CD) pipelines, and schedule regular penetration tests against inference APIs and model‑serving infrastructure. A public bug‑bounty or vulnerability‑disclosure program adds an extra layer of scrutiny.

Comprehensive monitoring and logging needs to be in place. Audit logs should be immutable for every data‑access event, model‑training job, and inference request, and feed them into a security information and event management (SIEM) platform that can generate real‑time alerts for anomalous behaviour. Retain logs for a period that satisfies regulatory mandates (e.g., 90 days for GDPR).

Speaking of inference requests, find out a) what is logged, and b) who sees it. These should be in line with what’s allowed contractually to protect privacy of employees and customers.

The vendor must maintain a documented incident‑response (IR) plan with clearly defined escalation contacts and response timelines. Evidence of at least a regular TTX is a bonus!

Clear backup and disaster‑recovery capabilities are also required. Be aware that cloud-hosted services in general don’t have backup tapes. I’ve seen so many questionnaires that insist on backup tapes. Perform daily encrypted backups stored in a geographically distinct region, and make sure the recovery‑time objective (RTO) recovery‑point objective (RPO) meet your org’s requirements.

Verify physical security of the data centers hosting the AI workloads. Look for certifications such as SOC 2 Type 2, ISO 27001, and on‑site controls like biometric access and 24/7 monitoring. Usually, the AI company is not the same as the host, so you’ll be redirected to the host’s site. Most likely, the AI company can’t share the host’s documentation due to being under an MNDA.

NOTE RE: ATTESTATIONS: Several AI vendors rely only on their hosts attestations yet note on their own site that “We are SOC 2 Type 2 certified and ISO 27001 compliant!” Check closely. This kind of statement may not be purposely misleading, but rather an indication that the vendor isn’t aware of how the attestation game needs to be played.

Your company needs to have a good handle on what it needs for the risk levels. E.g., “for a department to use an AI-something to share notes internally, we just need Privacy Policy, basic security policies, and know where the host is,” whereas, “If we might embed this in our product or use it to make corporate decisions, then we need to see ISO 27001, ISO 27701, ISO 42001, SOC 2 Type 2, and the AI policies.”

Vendor management was complicated before AI. Do what you need to do to vet properly, but don’t make it harder than it has to be.

AI Governance Within the Vendor’s Organization

A mature AI vendor will manage the model lifecycle with version control for datasets, code, and trained weights—using tools like Git combined with DVC or ML flow. Each model release should be accompanied by a model card that outlines its intended use, performance metrics, training‑data provenance, and known limitations. Automated regression testing should be triggered for every new version to guarantee that updates do not degrade accuracy or introduce regressions.

Reality: You may not need a card, and the vendor may not share model cards, but could instead point you to the model’s site for the cards used. But at least expect a solid answer if you ask.

Bias and fairness MUST be actively assessed. Before any model goes live, the vendor should run fairness metrics (e.g., disparate impact, equal‑opportunity scores) on representative test sets. A documented bias‑mitigation plan should be in place, and periodic re‑evaluations -at least annually - must be performed to catch drift or emerging inequities.

For high‑risk decisions, consider asking the vendor for explainability artifacts such as SHAP or LIME visualizations, feature‑importance rankings, and, where feasible, an API endpoint that returns a decision rationale. This transparency helps you satisfy regulatory demands (e.g., GDPR Article 22) and builds trust with end users.

The organization should publish an ethical AI policy that addresses safety, human oversight, privacy, and non‑discrimination.

If the AI solution is mission-critical to your company, you need to have access to the AI ethics policy or statement. Insist on it. If they don’t have it, then it doesn’t mean it’s a bad product - it just can’t be used for a critical solution. You will be asked – even audited – to ensure that your critical vendors are on the up-and-up.

With all the AI madness (remember – “slop” is the Merriam-Webster word of 2025), many AI vendors may have overlooked the need to be upfront about how they treat and approach AI.

You may not have the authority to say Yay or Nay, but make sure that, when applicable, you phrase your recommendations - in a professional way - to say what issues could crop up. With so much uncertainty about AI, you want to cover yourself as much as possible (cautions, date/time stamps, controls needed, implementation guidance, etc.).

Compliance with sector‑specific regulations must be demonstrable. Map AI processes to relevant statutes - GDPR, the upcoming EU AI Act, or industry‑specific rules - and maintain a compliance register that is refreshed with each model release. You need the vendor to demonstrate compliance, but it’s usually only done through their DPA, GDPR/CCPA/CPRA/etc. statements, Terms of Service/Terms & Conditions. And a refreshed compliance register? Not likely that you can get that from each vendor, but your creativity will make it possible to put something together.

If the vendor incorporates third‑party pretrained models, request a license‑compliance matrix and evidence that those external assets meet the same security and privacy standards you expect from the primary provider.

Transparency Through Open Source

Open‑source visibility is a strong indicator of a vendor’s commitment to accountability. If the AI solution’s codebase should is hosted in a public GitHub repo, ensure that your developers and implementers keep an eye on the Issues. That Issues page is public-facing, so criminals will know about the vulnerabilities, too.

Request a Software Bill of Materials (SBOM).

Assess the health of the open‑source community around the project. Active commit frequency, a diverse contributor base, and prompt issue responses are signs of a well‑maintained project; stagnation could indicate abandonment and heightened risk.

How old is the project? If it’s just a few months old, with not many contributors, issues, or responses, it might not be for you. This doesn’t mean that it’s bad, but if your org is counting on a good reputation, then having a brand new vendor may harm your reputation. The project could well be worth bookmarking and revisiting later on.

 Practical Vetting Checklist

1. Data Mapping – Obtain a Data‑Location Matrix, a detailed Data‑Flow Diagram, and a data‑classification report. Keep signed copies of these artifacts for audit purposes.
2. Legal Review – Secure the DPA, the URL to the vendor’s trust center, and copies of all relevant certifications (ISO 27001, SOC 2, etc.).
3. Security Audit – Request the most recent penetration‑testing report and the scope of the vendor’s ISO 27001 Information Security Management System.
4. AI Governance – Collect model cards, bias‑audit results, and the vendor’s AI ethics policy. These documents should be version‑controlled and regularly refreshed.
5. Open‑Source Transparency – Verify the public repository link, examine the issue backlog, and obtain an SBOM for the current release.
6. Ongoing Monitoring – Establish a quarterly review cadence for security and compliance, and define key‑performance indicators such as the percentage of issues resolved within 30 days.
7. Exit Planning – Confirm the procedures for data return and secure deletion at contract termination, and obtain a certification of completion once the process is executed.

A Plea to AI Vendors

AI vendors, please help ease the path of prospects and customers reviewing your product. I know the Privacy Policy is always at the bottom of a website for a reason – many people are only concerned with how a product operates. Yet more security, IT, Dev, and Engineering teams are tasked with ensuring more than just a good UX.

It’s surprising after all these years and technological innovations that there are so many companies that still operate slower than expect on information transfer. So often, there’s a slowdown somewhere along the way. The internet has gotten faster, automation capabilities are incredible, and the demand for diminishing friction in all areas so that Sales can be lean is at an all-time high. And yet, even many AI companies take days before they respond to a request for security documentation.

Reviews by security and IT teams are increasing, and AI companies need to know that. Until it’s reviewed accordingly, a sale doesn’t happen.

Security and IT teams need to do their part, too! They need to know that they are an integral part of the operations and sales pipelines. So, the process is not always slowed by the potential vendor.

If vendors want to streamline the process, thereby making more sales and money, then it’s critical to transfer that information as quickly as possible

It helps to have a Trust Center. I know – brand-name Trust Centers are expensive; even if done in-house, they’re expensive in the sense of hosting costs and maintenance hours. Even something like  Ally Security’s Trust Center (https://ally-security.notion.site/Ally-Security-Trust-Center-1be299d5994b45bb8c0769a32af33917) is of great value to those of us who have to review apps. It can be a simple and well-structured page.

The individuals reviewing the ever-increasing list of items to ensure their corporate and customer data stays safe face a concomitant increase in what they have to look through. Is the data center noted in the MSA, or the DPA, or the Privacy Policy, or, or…? Where’s the list of subprocessors? What security attestations, if any, do you have? I’ve seen so many that say they have SOC 2 and/or ISO 27001, but there’s no sign of it on their site other than a badge. Often, I resort to ChatGPT or Perplexity to find out if there’s a Trust Center for company ABC. Many times, I only find it via the bots. Be proud of those attestations! They’re expensive – so if you went through it, make it EASY to find them. Sure, you’ll want an MNDA, especially for the confidential information in many of those reports. But make it feasible.

A couple good items to invest the time and effort in are the following free self-assessments:

1.     CAIQ – CSA STAR Level 1

a.     https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4/

2.     HECVAT

a.     https://www.educause.edu/higher-education-community-vendor-assessment-toolkit

ISO 42001 – Artificial Intelligence (AI) Risk Management

What good AI conversation can be had without talking about ISO 42001?

ISO 42001 establishes a system‑wide framework for identifying, assessing, treating, and monitoring risks that arise from the design, development, deployment, and use of AI systems. Its purpose? Help organizations embed responsible AI practices while still being able to reap AI’s benefits. The standard is built around a set of guiding principles that shape every step of the AI‑risk‑management lifecycle.

If a vendor shows the ISO 42001 badge, great! But that’s pricey, so they may say “we are compliant with ISO 42001 principles.” That means that, while they haven’t passed an ISO 42001 audit, at least their AIMS (Artificial Intelligence Management System) is tracking with the international Standards. And that’s a good thing.

While there’s no official chart, below is an unofficial summary of those principles. I hope this chart helps in figuring out what a good AI governance program looks like.

Happy New Year!

SecjuiceCON is an online event for infosec and OSINT industry insiders, and we'd love for you to talk to our audience about your wisdom and learnings.

You might already know about our work, but Secjuice is the only non-profit, independent, and volunteer-led publication in the information security space.

We are a private members' writing club focused on cybersecurity, information security, hacking, and open-source intelligence gathering.

We believe that our value as professionals lies in our ability to share our research and knowledge with others through the written word.

We mentor hackers and help them prepare their research for publication.

Our members feel a strong sense of civic duty; it's what drives us to spread our knowledge and experiences with our community.

Defending the interests of those who hack is within our remit.

Call for Presenters

Please visit https://sessionize.com/SecjuiceCon2026/ to submit an abstract.

The deadline to submit is 1/31/2025.

Conference Date

Planning for Sunday, May 31, 2026

12 PM Eastern Daylight Savings Time (EDT)

4 PM Coordinated Universal Time (UTC)

Venue

YouTube Premier Video

https://www.youtube.com/@secjuice

Sponsors

We thank the following sponsors.

Gold Sponsors

• Sessionize.com

Bronze Sponsors

• DevITJobs.uk

Want to sponsor SecjuiceCON?

Please email conference at secjuice dot com to get more details!!

Topics

SecjuiceCON will cover the following topics and welcome speaker applications around these topics on any subject:

• Artificial Intelligence & Threat Intelligence
• Incident Response & Digital Forensics
• Security Architecture & Engineering
• Governance, Risk & Compliance
• Red, Blue & Purple Teaming
• Future Horizons & Emerging Threats
• Give Us What You Got

Schedule and Presenters

The schedule uses the America/New_York or Eastern Daylight Time.

• TBD

The schedule is tentative and subject to change.

Code Of Conduct

No drama, no hostility, maintain civility, or else.

When I started my organization’s CMMC journey, I knew I was stepping into one of the most important projects of my career. As a Department of Defense subcontractor, our business depends heavily on contract awards from large prime contractors. When I learned that CMMC would roll out in phases, where certified companies receive priority in Phase 1 and non-certified organizations could be excluded entirely in Phase 2.

I committed myself to:

“I will not be responsible for putting this company out of business.”

That clarity of purpose fueled every decision I made. We ultimately succeeded, earning a CMMC Conditional Certification with only one POAM, and later achieving the full certification. But the journey wasn’t flawless. I am sharing what worked, what I would do differently, and how you can prepare for your own assessment.

What I Did Well

1. Taking the CMMC Certified Professional (CCP) Course

One of the best decisions I made early on was completing the CCP training. I was not trying to become an auditor—I wanted to understand how auditors think.

The course gave me:

• A strong understanding of CMMC history and intent
• Clarity on the three evaluation methods: examine, interview, test
• Insight into what auditable evidence actually looks like

This foundation removed guesswork and let me structure our implementation around defensible, auditable evidence instead of assumptions.

2. Following a Proven Audit Preparation Plan

Our Quality Manager (QM), who leads our AS9100 audits every year, gave us a plan that became the backbone of our preparation. It was simple, realistic, and highly effective:

Year-long audit readiness plan:

• Step 1: Hire an external CMMC consultant to conduct an initial assessment and create an implementation plan.
• Step 2 (6 months later): Have the actual CMMC auditor perform a gap assessment.
• Step 3 (6 months later): Conduct the pre-assessment—the final gate before the real assessment.

This phased approach made expectations clear and prevented surprises late in the journey.

3. Using an Auditing Firm We Already Knew

We selected the same audit organization that handles our other certifications.

That mattered because:

• They already understood our business operations.
• We didn’t waste assessment time explaining our structure.
• They referred us to a consultant whom they trusted and worked well with.

Relationships matter in this process. Familiarity reduced friction and helped us avoid misunderstandings during evidence inspection.

4. Implementing Requirements In-House (With Help)

We chose to implement the consultant’s findings ourselves rather than outsourcing every change. It wasn’t always fast—but it worked.

Benefits of the DIY approach:

• We built internal competency.
• We tailored policies and procedures to our real business operations.
• We avoided forcing the company to conform to “canned” templates.

Ironically, during our final assessment, we learned that our consultant’s other clients had more findings than we did. That validated our more hands-on approach.

5. Setting Realistic Expectations With Leadership

I made it clear early on that the goal wasn’t a perfect 110 score.

The real objective was:

• Pass all 3-point and 5-point controls, and
• Get at least 80% with allowable POAMs

This mindset kept leadership aligned and supportive. When we earned a conditional certification with one POAM, they understood it was a success, not a failure.

What I Wish I Had Done Differently

1. Securing an Executive-Level Champion

I reported to an IT Manager who didn’t have enough organizational influence to push company-wide changes. I was four levels down from the CEO, yet responsible for implementing policies that affected the entire organization.

Without a champion at the director/VP/C-suite level:

• I spent countless hours negotiating and socializing changes.
• Adoption took longer than it needed to.
• Enforcement became a constant battle.

If I could start over, I would secure an executive sponsor from day one. It would be someone who could clear resistance and endorse changes from the top.

2. Defining a CMMC Enclave Early

Our leadership wanted the entire company to be certified instead of just the handful of employees who actually handle CUI. Looking back, this was one of our biggest inefficiencies.

The analogy I use is PCI compliance: Imagine certifying a 500-employee company for credit card handling when only 10 employees actually process payments. Now everyone—from custodians to executives—must take PCI training and follow PCI procedures.

That’s what we did with CMMC, and that added an excessive and unnecessary burden to everyone.

Yet, having a small, well-structured enclave would have:

• Reduced training
• Eliminated unnecessary policy scope
• Simplified implementation
• Reduced audit burden
• Improved overall compliance

I strongly recommend assessing whether your organization truly needs enterprise-wide certification—or if an enclave is the smarter path.

3. Involving the Quality Manager Earlier

Leadership was anxious about whether we would pass, so they instructed the QM to audit all evidence during the final month before the assessment.

The result?

• I worked 7 days a week, rushing to restructure evidence.
• We survived—but it was unnecessary stress.

If I had involved the QM throughout the entire program, the evidence format would have been clean, consistent, and audit-ready from the start.

The Final Result

We earned a CMMC Conditional Certification with one POAM during the final assessment period.

We closed that POAM within five months and achieved full CMMC Certification.

This journey pushed me professionally and personally, and I’m proud of the outcome. The lessons above aren’t hypothetical: they’re battle-tested. If you’re preparing for your own assessment, I hope these insights help you navigate your path more efficiently and with fewer surprises.

Closing Thoughts

CMMC is challenging, especially if you work for a small or mid-sized contractor. But with the right structure, the right people, and realistic expectations, it’s absolutely achievable.

If you’re getting ready for your final assessment:

• Invest in training.
• Choose your partners wisely.
• Secure an executive champion.
• Scope your environment thoughtfully.

And remember: the goal isn’t perfection—it’s certification.

Before You Go

Wishing you much success in your CMMC certification journey.

Sign up for my mailing list at https://miguelacallesmba.medium.com/subscribe

Jumping into the ring for a second round of Unusual Journeys into Infosec, reaching for the ladder of inspiration we aim to pin down what makes this industry great. This week we are joined by Phillip Wylie who has a really unusual journey.

I was first introduced to Phillip on The Many Hats Club discord where he shared his story, and even created a special role for him. When we kicked off the second season of this series, Guise Bule asked him to reach out to me on Twitter and the rest is history, as they say.

I'm a big fan of Phillip and don't want to spoil his story in this introduction, this is however, another example of how hard work, dedication, and facing into challenges really pays off. This is Phillip Wylie's Unusual Journey Into Infosec.

CyberSecStu (CSS): My vision for this article (or series), is to help break the illusion that you have to follow a certain route to have a career in Infosec. I have so many questions about your story, where did your journey begin?

Phillip Wylie (PW): I didn't take high school serious enough. Not finishing was never an option. My GPA was too low and my college entrance exam score was too low for my GPA. So I gave up prematurely on college. I had no idea what I wanted to do for a career. Since I was a big muscular guy from powerlifting, my friends recommended pro wrestling. This was a very interesting career path. I signed up at a wrestling school in Dallas, TX. After being trained to wrestle I started getting wrestling matches.

I wrestled in the WCW and it was at the time the WCW bought the UWF. I had several televised matches with the WCW and a wrestling federation based out of Dallas, TX called the WCCW.

My pro wrestling career lasted about two years with one year of training before I got matches. I got married and got out of wrestling a little over a year later. I didn't make enough money wrestling, so my main source of income was working as a bouncer at a nightclub in my home town in Denton, TX.

The nightclub hosted special events on Sundays to bring in a crowd. Sundays were typically slow unless there was something special going on.

The nightclub planned an event which entailed a wrestling bear. It was open to anyone to wrestle the bear, but they asked me to wrestle the bear. They used my wrestling promo picture on the posters and flyers announcing the event.

The bear was named Sampson and he was a 750lb brown bear. There were others that wrestled the bear. I did not beat the bear, but I did the best. I won a bar tab and a T-Shirt that read "I wrestled Sampson The Bear and lost."

I wrestled Sampson twice and after the first time I wasn't going to wrestle him again, but a couple hours later and taking advantage of the bar tab, the club owner easily convinced me to wrestle the bear a second time. I got out of wrestling due to getting married and needing a more stable income, I worked in retail, retail sales, restaurants, and manual labor.

After my daughter was born I realized that I needed something better with health insurance. I saw a commercial on TV about a trade school that taught computer-aided design (CAD). I enrolled in the school. This was in the Fall of 1992. I did not have any experience with computers. I graduated in the Fall of 1993 and got a job as a CAD draftsman. I discovered after working as a draftsman, that I had more of a talent for computers. I would troubleshoot and resolve problems that my coworkers were having. In 1995 I taught myself how to build computers and I was introduced to the role of a system administrator. I learned that they made about $10 an hour more than what I was making. In 1997 I took a 90 Novell NetWare course and after completion, I went to work as a system administrator.

I worked as a system administrator from September 1997 to December 2003 and I moved into a network security role.

I worked in network security from January 2004 to September 2005. My employer hired a CISO and he separated our department into different security functions. Prior to this we all did network security. I was put in an application security role.

This role inspired me to become a pentester. In the Fall of 2011, the company I was working for announced the sale of the mortgage division, which I worked in. On the all-hands call announcing the sale, they said if the division was not sold it would be shutdown. I started to apply for jobs. In March 2012 I got a consulting job performing pentests.

I've been pentesting since then and started teaching pentesting January 2018 at Richland College in Dallas, TX. My passion for pentesting and teaching led me to start The Pwn School Project as a way to educate people on pentesting and security. I host two meetings a month. One in Dallas, TX and one in Denton, TX. I also enjoy speaking at conferences and teaching workshops.

CSS: This is all amazing! You've been in Infosec for a while now, what do you see as the biggest challenges for people trying to break into the industry? Second part to this, have these (OR How have these), changed from when you first started?

PW: I think the biggest challenge with people that are trying to break into the industry is finding companies that are willing to give people with no experience a chance. The best way to deal with this is through networking. Attending local infosec meetings and conferences are great ways to network. Through networking, those looking to break in the industry are able to get their resumes to hiring managers directly or from others working for the hiring company.

I think the biggest change since I started is that security jobs are a lot more in demand, but it doesn't make it easy to get into infosec. Internships are a good way for students or college grads to get into security. My wife works in DFIR and got her job through an internship

CSS: Awesome, love this. Internships and apprenticeships are a decent route.

PW: It amazes me how difficult it can be and there is a shortage of security people.

CSS: What do you think companies should be doing to help attract more people or bridge the gap?

PW: I think internships, apprenticeships, and temporary contract jobs would help bridge the gap. Companies wouldn't have to commit to long term employment and they would get to see if candidates have potential. Apprenticeships and temp contract jobs could be open to not only students or grads, but they could also be open to those moving from IT to security or those that have gone the self-study route.

CSS: What is the best advice you've been given by someone in infosec on your journey so far, OR you've given?

PW: The best advice I have given is to network through local infosec meetings and conferences. Getting involved in the community makes it easier to find jobs. I got my last two full-time jobs through meetups. Networking and community involvement is a good way to share and learn. My experience with the infosec community has been rewarding and my best friends are from the community.

I share this with students and people I mentor. As well as anyone else looking for advice.

CSS: Very close to my heart, cons and meetups are really valuable, and helped me no end when starting out.

Okay, so is there anything you want to share or anyone you want to give a shout out to?

PW: I would like to give a shout out to my Dallas/Fort Worth infosec and hacking community. Dallas Hackers Association has done so much to grow and improve our local community and part of the inspiration for my meetup The Pwn School Project. I would also like to give a shout out to my friend on Infosec Twitter.

CSS: Thank you so much for sharing your story it's going to help a lot of people. One final question I have to ask (well it wasn't for sure). What was it like wrestling an actual bear?

PW: It's tough and nearly impossible. Trying to move a 750 pound bear is like trying to move a parked car, it will barely move. The bear I wrestled was very tame and like a big dog. It was a fun experience that I would not do again.

CSS: Kudos to you for doing it though!

PW: It's probably not legal in the US anymore with the protections around animals. Even back in the late 1980's there were rules that made sure the bear got mandatory rest periods.

I was involved in Rachel Tobac's Non-Linear Paths to InfoSec talk at BSides San Francisco in February and I use it on my slide when I was telling my story.

CSS: That's awesome, and also glad the bear got a rest. Still the craziest thing I've heard in a while! Thank you Phillip you're a star!

PW: Thanks for the opportunity, Stu! I had some crazy things happen when I was younger. I was also shot when I was 15 years old.

CSS: Wait you were shot when 15, what happened?

PW: My history of being shot, wrestling, wrestling a bear and powerlifting has earned me the nickname the Chuck Norris of infosec.

My brother was playing with a gun and shot me. He did not know that it was loaded.

CSS: Damn!! That's gotta leave a mental scar, for like both of you!

PW: He was 11 years old and trying to impress a neighbor's kid. The bullet went in through my left arm, then into my side. It entered my lung and pumped out of my lung into my heart. From my heart it lodged into the bend of my left leg.

When the paramedics got me to the hospital, they took x-rays and saw the bullet was in my heart. They transferred me 36 miles from Denton, TX to Dallas, TX to Parkland Hospital the leading trauma center in the area and the same hospital that JFK was sent to.

When I got there they cracked my chest open and didn't see an entry wound on my heart. They took an x-ray and the bullet was no longer there. It pumped into my leg.

CSS: You're like a machine, gets shot, pro wrestler, bear wrestler, and infosec pro! So they got the bullet out I assume. How long did it take to recover?

PW: It's a miracle I lived to tell about it. The bullet is still there. I have an x-ray of it.

CSS: You're like proof of no matter what happens in your life - you can still achieve anything!!!!

PW: The summer before I got shot I started lifted and when I wasn't sure that I would survive, I was worried about my classmates beating my bench press. Years ago I did not think I had the intelligence or potential to do what I am now doing. Hopefully, it will encourage others.

CSS: Thank you for sharing, this story definitely will inspire loads of people.

There is so much inspiration from this story to summarise in a mere paragraph, I think as Phillip has proven, that no matter what happens in your life, you can still achieve your potential. Again getting involved in the community, going to meetups and networking is vital to making those important connections. Having hosted, and attended many meetups, I cannot stress the importance of this!

In summary, go wrestle a bear- which is now a metaphor for tackling those big fears and challenges in your life, because if you can do that, anything is possible!

The amazing image is called Arm Wrestling and is by Danilo De Donno go check them out!

The OODA loop is a four-step model used in intelligence for decision making that involves analyzing information and acting on it. In this article, I explain the roots of its history, its applications in combat operations, and how it can be utilized for time-sensitive decision making processes in cybersecurity, including other areas of our lives.

History

OODA is an acronym for observe, orient, decide, and act. It was developed in the 1960s by a man named John Boyd who was a Colonel in the United States Air Force as a fighter pilot, military researcher, and strategist. He came up with the concept after his experiences in the Korean War, realizing that a fighter pilot is at a disadvantage when dealing with an adversary who is more equipped and advanced than they are. The OODA loop model became developed as a result.

Model of Choice

Inevitably, the OODA loop became a model of choice for combat operations, which required a decision making process that can be effectively executed during critical and time-sensitive events. Indeed, the OODA loop model was proven as effective for decision-making with its recurring cycle of observe–orient–decide–act. In fact, the model can be used for any problem or issue that requires strategic decision-making. Not limited to areas such as business, medical, management, litigation, marketing, and especially cybersecurity.

The four stages of the OODA Loop Model

1. Observe:
The Observe stage is the information gathering process. This is the stage when you gather as much information that you possibly can regarding something. For example, a doctor first needs to gather all the information they need about a patient’s body in order to determine if anything is not functioning properly. They will observe a patient’s body and will notice if there is abnormal swelling or pain in a particular area and take a look at their lab results to determine if further testing or treatment needs to be done. In the event that a company or organization’s network becomes attacked, an information security or cybersecurity analyst on their technical security team is often the first to observe the network attacker, and will try to capture them by gathering logs, monitoring systems, and collecting any further information that will help them identify the attacker.

2. Orient:
The Orient stage puts the information gathered from the Observe stage into context. This is when everything is taken into account ranging from past experiences of dealing with a situation at hand or particular thing, preconceived notions, outcomes, expectations, and models. Let’s say a doctor notices a patient has an abnormal lump in their throat about the size of a golf ball. That doctor will take into account all the past experiences he had with patients that had the same problem in order to help themselves determine what could possibly be happening, to help them determine what direction to take for treating their patient. As far as dealing with a network attacker in the prior example, orientation takes the telemetry pulled from logs and combines it with knowledge about the network, APT groups who may target networks of those particular companies and organizations, and previously identified information such as specific IP addresses, devices used, and more.

3. Decide:
The Decide stage is when the final course of action is determined after considering a variety of options, but it is NOT the stage when you officially execute an action. In the case of a doctor who sees a patient with a lump in their throat that is the size of a golf ball, they can decide if the patient has cancer and needs chemotherapy or other alternative therapies based on their observational findings and analysis. Let’s say that the doctor decided the patient needs chemotherapy for this example. As far as dealing with the network attacker goes, this is the stage when a decision is made on whether the network attacker should continue to be observed to wait and see what their next move should be, to decide if they should be ignored instead, or if an incident-response action should be initiated. Regardless of the situation, a final course of action is decided in this stage.

4. Act:
The Act stage is when you execute the final course of action that was already decided. This is when you DO the action. It’s the point of no return where there is no turning back. What’s done is done. And it doesn’t necessarily mean what is done will be a 100% guaranteed success. Just like the doctor who decided their patient needs chemotherapy, it doesn’t mean that form of treatment will be 100% successful. The same applies to the network attacker (let’s say it was finally decided to ignore them which turned out to be a terrible idea). If the course of action acted upon doesn’t work, then we return to the whiteboard back to the OODA loop and start with the first stage of observation all over again. Observe–orient–decide–act becomes the loop that we rinse and repeat. Otherwise, the Act stage is final when successful.

The importance of OODA loop

The OODA loop is a simple four step process that is effective for decision-making, especially when time-sensitive situations are at hand, which is an important intelligence strategy that is useful in information security. OODA reveals how important it is to gather as much information as possible before filtering out what’s unnecessary when the context of information is considered in the orientation stage. The first two stages are critical in helping to decide what course of action needs to be acted on.

You can clearly recognize how prioritization in the decision-making process is crucial. For example, during the decision-making process in dealing with a particular situation at hand, it must be determined if it would be extremely destructive to ignore the situation, if it even requires an immediate or time-based response, or if it is a minor dealing that happens all the time and doesn’t require an intense response, etc. In intelligence analysis, energy must be focused on areas that demand our attention rather than being wasted on areas that are irrelevant or out of context based on the information we gathered. We can agree that this is an important intelligence model that we can apply not just to cybersecurity, but also to everything else outside of it in our daily lives.

When in doubt, use the OODA loop.

Hello everyone and welcome to another why you should adopt serverless computing special! There are some wonderful free or open source tools you can use to improve the security of your serverless projects. Let's explore some of them in this post.

1. Linters

Linters help improve your code by finding common coding flaws. You would typically run them when you create a pull request, create a build, or in your CI/CD.

• ESLint (Node): https://eslint.org
• Pylint (Python): https://www.pylint.org
• golanglint (golang): https://github.com/golang/lint

2. Dependency checkers

Your project might use dependencies, libraries, or packages. Some of these packages might be out-of-date, deprecated, or have known vulnerabilities. A dependency checker can help you find packages that need updating and create pull requests to update them automatically.

• npm audit (Node): https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities
• Snyk (Node, .Net, Java, Python, and more): https://snyk.io
• Dependabot (Node, Python, Java, .Net, and more): https://dependabot.com
• GitHub Dependabot (Node, Python, Java, .Net, and more): https://help.github.com/en/github/administering-a-repository/keeping-your-dependencies-updated-automatically

3. AWS IAM Roles

If you are using Amazon Web Services, your projects has IAM roles for your serverless functions. The Serverless Framework automatically creates one IAM role for all the functions in your configuration file. Each function should have its own IAM role to enable the Principle of Least Privilege.

• serverless-iam-roles-per-function Serverless plugin: https://github.com/functionalone/serverless-iam-roles-per-function
• serverless-plugin-custom-roles Serverless plugin: https://github.com/AntonBazhal/serverless-plugin-custom-roles
• Collection of AWS IAM policies for the Serverless Framework: https://github.com/miguel-a-calles-mba/serverless-policies

4. Error Monitoring and Alerting

Your functions may throw an error, but you may not know about it unless you manually monitor the logs or you setup an alerting system.

• Dashbird: https://dashbird.io
• Sentry: https://docs.sentry.io/platforms/node/guides/aws-lambda/ and https://github.com/arabold/serverless-sentry-plugin

5. Termination Protection

When you deploy a new AWS CloudFormation stack to production, you might want to enable termination protection to avoid accidentally deleting your stack.

• serverless-stack-termination-protection Serverless plugin: https://github.com/miguel-a-calles-mba/serverless-stack-termination-protection

Conclusion

You can improve the security of your serverless project by taking advantage of free or open source solutions that are already out there.

A Note from the Author

Join my mailing list to get updates on my writings, upcoming books, and cybersecurity news. Visit https://miguelacallesmba.com/subscribe to join.

Stay secure, Miguel

View my linkedIn profile

Follow @MiguelCallesMBA

The moment your LLC decides to hold cryptocurrency, you’ve crossed a threshold that most business owners never consider: you’re now responsible for securing private keys that represent real value. This isn’t theoretical.

This is infrastructure security at the most fundamental level.

Here’s the uncomfortable truth: traditional corporate security frameworks were never designed for crypto. Your IT team knows how to lock down servers, manage access controls, and implement multi-factor authentication across email systems. But crypto introduces a different animal entirely. One compromised private key means total asset loss. There’s no password reset. There’s no support team to call.

The money is simply gone.

The Attack Surface Nobody’s Talking About

When your LLC buys crypto through a standard exchange, you’re introducing new vulnerabilities into your corporate infrastructure. Exchange accounts get compromised. Not because exchanges are inherently weak, the institutional players like Coinbase Prime and Kraken have serious security, but because the human element always cracks first.

A founder gets a convincing phishing email. They click a link. Suddenly someone in Belarus has access to the exchange account. Or an employee gets socially engineered into approving a wire transfer to a wallet address that looks legitimate but isn’t. These aren’t hypothetical scenarios. This is what actually happens.

The cybersecurity implication is stark: if your LLC holds any meaningful amount of crypto, you need the same operational security protocols that nuclear facilities use. That’s not hyperbole. It’s proportional response to actual risk.

Private Key Management: The Hardest Problem in Crypto

Every security team knows the fundamental challenge: how do you secure something that, by design, cannot be recovered if lost? Traditional password management systems don’t work here. You can’t hash a private key and store it in a database. You can’t implement account recovery procedures.

The moment you compromise operational security around key management, your asset is vulnerable. This is why institutional custodians exist. Services like Spindipper, Coinbase Prime, and Kraken Institutional solve this through hardware security modules, multi-signature requirements, and airgapped infrastructure. They’re essentially applying crypto-specific security to the problem rather than trying to retrofit traditional corporate security practices.

But here’s what matters for your LLC: using a custodian isn’t weakness. It’s acknowledging that key management is a specialized security problem that requires specialized infrastructure. If your company is treating private keys like passwords, storing them in shared drives, emailing them, keeping backups in Dropbox, you’ve already lost.

The Human Factor: Your Biggest Vulnerability

Cryptocurrency security ultimately fails because of human error, not technical failure. An employee leaves and nobody removes their hardware wallet from the secure storage system. A finance person writes down a seed phrase and leaves it on a desk. Someone reuses passwords across personal and business accounts. These are the scenarios that actually compromise corporate crypto holdings.
Your LLC needs written security policies for every person with access to crypto infrastructure. That means defined procedures for wallet access, explicit requirements for multi-signature transactions, regular rotation of access credentials, and audit trails that log every action.

Most importantly, it means consequences for deviation. Security protocols fail when they’re optional. The cybersecurity team needs to treat crypto asset security with the same rigor as protecting customer data or intellectual property. Because frankly, if someone steals your customer database, you have legal liability and insurance claims. If someone steals your crypto, it just vanishes.

Cold Storage, Hot Wallets, and Operational Risk

Every crypto security framework involves this tension: you need liquidity for business operations, but liquid assets are vulnerable. A hot wallet connected to the internet can execute transactions instantly but gets compromised more easily. Cold storage is secure but slow. The solution most institutional operators use is layered: a small amount in hot storage for immediate operational needs (paying contractors, settlement), the bulk in cold storage (hardware wallets, airgapped systems, multi-sig arrangements that require physical presence to authorize), and everything audited and logged. Your LLC probably doesn’t need the complexity of a major exchange’s infrastructure, but the principles apply. Figure out the minimum amount you need liquid for daily operations. Put that in a hot wallet with appropriate controls. Everything else goes cold. Document it. Audit it.

Make it boring.

Compliance Documentation and Audit Trails

Here’s what most founders miss: your LLC’s crypto security posture will eventually be audited. Either by internal compliance, external auditors, tax authorities, or regulators. The documentation needs to exist in advance. That means records of how private keys are stored, who has access, what authorization procedures exist, what happened on every transaction date, and proof that the security measures are actually being followed. This is tedious. But the alternative, explaining to auditors why you have no documentation of how a million dollars in crypto is secured, is worse. Your cybersecurity team should be documenting the entire crypto infrastructure the same way they document every other critical system. Network diagrams. Access control matrices. Incident response procedures. The works.

Third-Party Risk and Vendor Assessment

When your LLC uses a custodian or exchange, you’re introducing third-party risk into your security posture. You need to evaluate that risk the same way you’d evaluate any critical vendor. What are their security certifications? Do they have SOC 2 compliance? What’s their incident response history? What happens if they get hacked? What insurance do they carry? These aren’t abstract questions. They’re the difference between losing corporate assets and having some recourse.
Most institutional custodians publish security documentation. Review it. Have your security team review it. Understand the attack scenarios where you’re still vulnerable even if the custodian is secure.

The Uncomfortable Conclusion

If your LLC is going to buy and trade crypto, you’re committing to a security posture that goes beyond standard business practices. You’re managing bearer instruments in a digital format where compromise means total loss. This isn’t a reason to avoid crypto. But it is a reason to approach it with the same rigor a financial services company brings to protecting customer accounts. Wrong approach and you’ll spend 2025 explaining to investors why the company’s digital assets got stolen because nobody documented the access procedures.

Get the security right. Everything else follows.

Many newcomers to open source intelligence immediately gravitate towards the tools and become reliant on them rather quickly. This becomes problematic when the tools break, become deprecated, or otherwise unavailable. While automation, collection assistance, and visualization tools can help immensely in an investigation, they cannot analyze the work and do your job for you.

One of my most repeated bits of advice for those new to OSINT or those wishing to improve their current OSINT skills is to go back to the basics, namely the intelligence cycle. This series of articles aims to reframe each phase of the intelligence cycle to show specifically how I apply it during one of my OSINT investigations.

Part One: Planning and Direction

The planning and direction phase of the OSINT intelligence cycle is where an analyst should determine their investigative requirements, outline what questions they are attempting to answer, and make note of any special circumstances that might arise due to the target, the situation, or the platforms that might be used.

At best, going into an OSINT investigation without a plan or direction can cause an investigation to take longer than needed. At worst? An investigator may lack the proper dependencies required for the investigation or risk being detected by the target due to technical oversights. During this phase of the intelligence cycle, I tend to take the following steps:

Identify what question(s) need to be answered:
Write down any questions that need to be answered as part of the investigation and avoid chasing tangents that do not assist in answering these questions. I tend to have one main question to answer, and many smaller questions that when combined may help answer the main question. The main question of “Who is behind this account?” might have subquestions such as: “What is their name?”, “What country are they in?”, “What is their approximate age?”, and "Are they on any other platforms?". Keep in mind it is perfectly fine to add, remove, or modify these questions as the investigation progresses.

Identify what platform(s) may need to be accessed:
Be sure to set up any required accounts and acquire any additional software or hardware before beginning the investigation. Early on, it may not be possible to know all of the platforms a target frequents. However, it is always a good idea to try and identify potential platforms and any prerequisites needed to access them based on the target's currently known information. Most mainstream social media platforms will share the same requirements, usually a sock puppet account and perhaps an email or telephone number for verification. However, if investigating a platform that is home to a small, tight-knit group that tends to be suspicious to outsiders they may have heightened requirements for new joiners. Some groups may require vetting by another member before allowing new users to join, which will require additional setup and prep.

Assess the technical capabilities of the target(s):
It is important to assess a target’s technical capabilities and if that might increase the chances of being detected during the investigation. Knowing how technologically savvy a target is might also offer insight into how likely they are to make technical mistakes. This isn’t always possible to answer in the planning stage, however as the intelligence cycle continues it may become clearer. While it doesn’t hurt to always assume a target contains advanced technological skills, it might not be feasible for every analyst to take state actor level precautions for every target. As a rule of thumb, I suggest taking precautions at a higher level than a target’s perceived technical abilities. Consider using an anonymous browser like Tiger404 to protect yourself when assessing a target's technical capabilities.

Determine end goal(s):
Set reasonable goals and expectations for the investigations and write them down. What is the expected outcome of the investigation? Will it result in a written report, notifying the authorities, or something else? Knowing the end goal ahead of time will help drive the OSINT investigation. Identifying the end goal(s) help keep an investigation on track and will assist in making decisions during the other phases that may be dependent on the end goals.

Conclusion

The planning and direction phase of an OSINT investigation helps an investigator start off on the right foot by ensuring they have what is needed to begin investigating a target. This phase of the OSINT intelligence cycle is critical to mitigating time lost spent going down unrelated rabbit holes or setting up accounts mid-investigation. Once an investigator completes initial work in the planning and direction phase, it is time to move on to the next phase of the intelligence cycle: Collection.