TandT LLC

Blog

  • ISO/IEC 42001 Is Not a Policy Document

    When a board asks for “an AI governance policy,” what often gets produced is a document: a few pages describing principles like fairness, transparency, and accountability, circulated for sign-off, then filed away until the next audit. It satisfies the request on paper. It does very little to actually manage the risk of an AI system making a bad decision in production.

    ISO/IEC 42001, the international standard for AI management systems, asks for something different. Not a statement of intent, but a system: a defined process for how AI use cases get identified, assessed for risk, approved, monitored, and improved, with evidence that the process is actually being followed.

    Use Case Inventory Comes Before Anything Else

    You cannot govern what you have not inventoried. A surprising number of organizations, when asked directly, cannot produce a complete list of where AI or machine learning is actually being used across the business. A model embedded in a vendor product counts. An internal tool a team built to triage support tickets counts. A generative AI assistant employees are using informally, without an approved workflow, counts too, and is often the largest source of unmanaged risk.

    The starting point under 42001 is a real inventory: every AI use case, who owns it, what data it touches, and what decision it influences. That inventory is what everything else in the standard hangs off of.

    Risk Review Has to Be Specific to Each Use Case

    A single generic risk statement covering every AI system in the company does not meet the intent of the standard, and it does not actually manage risk either. A model that recommends product bundles carries a very different risk profile than one that influences a hiring decision or a credit decision. 42001 expects the risk assessment to reflect that difference: what happens if this specific model is wrong, who is affected, and what controls exist to catch it before it causes harm.

    Monitoring Is the Part Most Programs Skip

    A model approved a year ago, on the data available a year ago, is not the same model running today if the underlying data has shifted, or if the vendor has quietly updated the model behind the scenes. Ongoing monitoring, not a one-time approval, is what the standard actually requires: a defined way to catch when a model’s behavior drifts from what was originally assessed and approved, and a process for re-review when it does.

    What Certification Readiness Actually Looks Like

    Getting ready for a 42001 assessment is less about writing new policy and more about building the evidence trail: the use case inventory, the risk assessments tied to each entry in it, the approval records, and the monitoring logs that show the system is a living process rather than a document that was signed once. That is the gap between organizations that pass and organizations that need another cycle: not effort, but evidence.

    If you are trying to figure out how far your current AI governance approach is from what an assessor would actually want to see, that is exactly the kind of independent review our AI Assurance & Responsible AI team runs.

  • Why Technology Due Diligence Needs Someone Who Is Not in the Deal

    By the time a target company’s technology stack reaches a private equity sponsor’s desk, it has usually already been through a round of polishing. The architecture diagram is current. The pitch deck describes a modern, cloud-native platform. What that picture often leaves out is not deception. It is the normal accumulation of shortcuts a growing company takes under deadline pressure, none of which show up cleanly in a slide.

    Sellers Describe the System They Wish They Had

    This is not usually intentional. A founder or CTO genuinely believes the architecture is sound because they remember designing it that way. What they do not always track closely is how much has drifted since: the integration that was supposed to be temporary and is now load-bearing, the database migration that got 80 percent finished before priorities shifted, the security control that was implemented for one product line but never extended to the others after an acquisition.

    A reviewer with a stake in getting the deal done, whether that is the seller’s own team or an integrator who wants the follow-on implementation work, has a natural incentive to describe the system in its best light. That is not a criticism of their honesty. It is simply what happens when the person assessing a system also has a reason to want it to look good.

    The Questions an Outside Reviewer Actually Asks

    An independent technical reviewer with no stake in whether the deal closes asks different questions than a sales-oriented walkthrough does. Not “does this architecture make sense,” but “show me the last three production incidents and what actually caused them.” Not “is the code well organized,” but “how much of this is one engineer’s undocumented knowledge, and what happens if they leave in month two of the hold period.”

    Those questions surface the kind of technical debt that does not show up in an architecture diagram: brittle integrations, scaling limits the team has quietly worked around rather than fixed, and security gaps that were accepted as a known risk years ago and never revisited.

    What This Changes for the Deal Itself

    A clear-eyed technology review before close does not usually kill deals. What it does is change the terms: a lower valuation that reflects real remediation cost, a holdback tied to specific fixes, or simply a hundred-day plan that starts with the right priorities instead of discovering them six months into the hold period, after the sponsor’s own team has already taken ownership.

    That is the role we play. We are not the integrator hoping to win the next phase of work, and we are not the seller’s team explaining their own decisions. We are an independent technical opinion, built on evidence the sponsor can act on, delivered before the wire goes out rather than after.

  • ISO/IEC 42001 Is Not a Policy Document

    When a board asks for “an AI governance policy,” what often gets produced is a document: a few pages describing principles like fairness, transparency, and accountability, circulated for sign-off, then filed away until the next audit. It satisfies the request on paper. It does very little to actually manage the risk of an AI system making a bad decision in production.

    ISO/IEC 42001, the international standard for AI management systems, asks for something different. Not a statement of intent, but a system: a defined process for how AI use cases get identified, assessed for risk, approved, monitored, and improved, with evidence that the process is actually being followed.

    Use Case Inventory Comes Before Anything Else

    You cannot govern what you have not inventoried. A surprising number of organizations, when asked directly, cannot produce a complete list of where AI or machine learning is actually being used across the business. A model embedded in a vendor product counts. An internal tool a team built to triage support tickets counts. A generative AI assistant employees are using informally, without an approved workflow, counts too, and is often the largest source of unmanaged risk.

    The starting point under 42001 is a real inventory: every AI use case, who owns it, what data it touches, and what decision it influences. That inventory is what everything else in the standard hangs off of.

    Risk Review Has to Be Specific to Each Use Case

    A single generic risk statement covering every AI system in the company does not meet the intent of the standard, and it does not actually manage risk either. A model that recommends product bundles carries a very different risk profile than one that influences a hiring decision or a credit decision. 42001 expects the risk assessment to reflect that difference: what happens if this specific model is wrong, who is affected, and what controls exist to catch it before it causes harm.

    Monitoring Is the Part Most Programs Skip

    A model approved a year ago, on the data available a year ago, is not the same model running today if the underlying data has shifted, or if the vendor has quietly updated the model behind the scenes. Ongoing monitoring, not a one-time approval, is what the standard actually requires: a defined way to catch when a model’s behavior drifts from what was originally assessed and approved, and a process for re-review when it does.

    What Certification Readiness Actually Looks Like

    Getting ready for a 42001 assessment is less about writing new policy and more about building the evidence trail: the use case inventory, the risk assessments tied to each entry in it, the approval records, and the monitoring logs that show the system is a living process rather than a document that was signed once. That is the gap between organizations that pass and organizations that need another cycle: not effort, but evidence.

    If you are trying to figure out how far your current AI governance approach is from what an assessor would actually want to see, that is exactly the kind of independent review our AI Assurance & Responsible AI team runs.

  • Why Cybersecurity Compliance Matters for Modern Businesses

    By TandT LLC | September 1, 2026

    Cybersecurity is no longer only an IT responsibility. For modern organizations, protecting sensitive information, managing technology risks, and meeting cybersecurity requirements are essential parts of doing business.

    As organizations become more dependent on cloud platforms, remote work, artificial intelligence, and connected systems, the potential impact of a security incident continues to grow. A strong cybersecurity compliance program helps organizations understand their risks, establish appropriate safeguards, and demonstrate that security is being managed responsibly.

    What Is Cybersecurity Compliance?

    Cybersecurity compliance is the process of aligning an organization’s security practices with applicable regulations, standards, contractual requirements, and industry frameworks.

    Compliance may involve areas such as:

    • Access control and identity management
    • Data protection
    • Security policies and procedures
    • Risk management
    • Incident response
    • Employee security awareness
    • System monitoring
    • Vulnerability management
    • Vendor and third-party risk

    The specific requirements depend on the organization, industry, customers, and regulatory environment.

    Why Compliance Is Important

    A compliance program provides more than documentation. When implemented properly, it creates a structured approach to managing cybersecurity risks.

    1. Protect Sensitive Information

    Organizations routinely handle confidential business information, customer data, employee information, intellectual property, and other sensitive records. Appropriate security controls help reduce the risk of unauthorized access, data loss, and cyberattacks.

    2. Reduce Cybersecurity Risk

    Compliance frameworks provide organizations with a structured way to identify weaknesses and implement security controls. This can help organizations move from a reactive security approach toward proactive risk management.

    3. Meet Customer Requirements

    Many organizations must demonstrate their cybersecurity capabilities before working with larger customers or government organizations. Security certifications, assessments, and compliance documentation can help demonstrate that appropriate controls are in place.

    4. Improve Business Resilience

    Cybersecurity incidents can interrupt operations, damage customer trust, and create significant financial and reputational consequences. A mature compliance program can strengthen an organization’s ability to prevent, respond to, and recover from security incidents.

    Compliance Is Not the Same as Security

    One important distinction is that compliance and cybersecurity are related, but they are not identical.

    Compliance focuses on meeting defined requirements and demonstrating that appropriate controls and processes exist. Cybersecurity focuses more broadly on protecting systems, information, people, and business operations from threats.

    An organization can technically meet a compliance requirement while still having security weaknesses.

    The strongest programs therefore treat compliance as part of a broader cybersecurity and risk-management strategy.

    Building a Strong Compliance Program

    Organizations can start by establishing a clear understanding of their current security environment.

    A practical approach includes:

    1. Identify applicable requirements
      Determine which regulations, contracts, standards, or frameworks apply to the organization.
    2. Assess the current environment
      Review existing policies, technologies, processes, and security controls.
    3. Identify gaps
      Compare the current environment against the applicable requirements.
    4. Prioritize risks
      Focus first on weaknesses that could create the greatest security or business impact.
    5. Implement appropriate controls
      Establish technical, administrative, and physical safeguards based on identified requirements and risks.
    6. Document policies and evidence
      Maintain the documentation and evidence needed to demonstrate that controls are operating effectively.
    7. Continuously monitor and improve
      Cybersecurity requirements and threats change over time, so compliance should be treated as an ongoing program rather than a one-time project.

    The Role of Leadership

    Cybersecurity compliance should not exist only within the IT department. Leadership plays an important role in establishing priorities, allocating resources, defining responsibilities, and creating a culture where security is treated as a business priority.

    Clear accountability helps ensure that cybersecurity requirements are integrated into everyday business operations.

    Frequently Asked Questions

    Is cybersecurity compliance only for large organizations?

    No. Organizations of different sizes may have cybersecurity obligations based on their customers, contracts, industry, regulations, or the type of information they handle.

    Does compliance guarantee that an organization cannot be hacked?

    No. Compliance can help establish and maintain security controls, but no program can guarantee complete protection from cyber threats.

    How often should an organization review its compliance program?

    Organizations should continuously monitor their security environment and review their compliance requirements regularly. Significant changes to technology, business operations, regulations, or threat conditions should also trigger a review.

    Conclusion

    Cybersecurity compliance should be viewed as an ongoing business discipline rather than a checklist completed once a year.

    By understanding applicable requirements, identifying security gaps, implementing appropriate controls, maintaining evidence, and continuously improving their security program, organizations can strengthen their cybersecurity posture while building greater confidence with customers, partners, and stakeholders.

    TandT LLC helps organizations understand cybersecurity requirements, strengthen security programs, and prepare for compliance and assurance needs.

  • ISO/IEC 42001 Is Not a Policy Document

    When a board asks for “an AI governance policy,” what often gets produced is a document: a few pages describing principles like fairness, transparency, and accountability, circulated for sign-off, then filed away until the next audit. It satisfies the request on paper. It does very little to actually manage the risk of an AI system making a bad decision in production.

    ISO/IEC 42001, the international standard for AI management systems, asks for something different. Not a statement of intent, but a system: a defined process for how AI use cases get identified, assessed for risk, approved, monitored, and improved, with evidence that the process is actually being followed.

    Use Case Inventory Comes Before Anything Else

    You cannot govern what you have not inventoried. A surprising number of organizations, when asked directly, cannot produce a complete list of where AI or machine learning is actually being used across the business. A model embedded in a vendor product counts. An internal tool a team built to triage support tickets counts. A generative AI assistant employees are using informally, without an approved workflow, counts too, and is often the largest source of unmanaged risk.

    The starting point under 42001 is a real inventory: every AI use case, who owns it, what data it touches, and what decision it influences. That inventory is what everything else in the standard hangs off of.

    Risk Review Has to Be Specific to Each Use Case

    A single generic risk statement covering every AI system in the company does not meet the intent of the standard, and it does not actually manage risk either. A model that recommends product bundles carries a very different risk profile than one that influences a hiring decision or a credit decision. 42001 expects the risk assessment to reflect that difference: what happens if this specific model is wrong, who is affected, and what controls exist to catch it before it causes harm.

    Monitoring Is the Part Most Programs Skip

    A model approved a year ago, on the data available a year ago, is not the same model running today if the underlying data has shifted, or if the vendor has quietly updated the model behind the scenes. Ongoing monitoring, not a one-time approval, is what the standard actually requires: a defined way to catch when a model’s behavior drifts from what was originally assessed and approved, and a process for re-review when it does.

    What Certification Readiness Actually Looks Like

    Getting ready for a 42001 assessment is less about writing new policy and more about building the evidence trail: the use case inventory, the risk assessments tied to each entry in it, the approval records, and the monitoring logs that show the system is a living process rather than a document that was signed once. That is the gap between organizations that pass and organizations that need another cycle: not effort, but evidence.

    If you are trying to figure out how far your current AI governance approach is from what an assessor would actually want to see, that is exactly the kind of independent review our AI Assurance & Responsible AI team runs.

  • ISO/IEC 42001 Is Not a Policy Document

    When a board asks for “an AI governance policy,” what often gets produced is a document: a few pages describing principles like fairness, transparency, and accountability, circulated for sign-off, then filed away until the next audit. It satisfies the request on paper. It does very little to actually manage the risk of an AI system making a bad decision in production.

    ISO/IEC 42001, the international standard for AI management systems, asks for something different. Not a statement of intent, but a system: a defined process for how AI use cases get identified, assessed for risk, approved, monitored, and improved, with evidence that the process is actually being followed.

    Use Case Inventory Comes Before Anything Else

    You cannot govern what you have not inventoried. A surprising number of organizations, when asked directly, cannot produce a complete list of where AI or machine learning is actually being used across the business. A model embedded in a vendor product counts. An internal tool a team built to triage support tickets counts. A generative AI assistant employees are using informally, without an approved workflow, counts too, and is often the largest source of unmanaged risk.

    The starting point under 42001 is a real inventory: every AI use case, who owns it, what data it touches, and what decision it influences. That inventory is what everything else in the standard hangs off of.

    Risk Review Has to Be Specific to Each Use Case

    A single generic risk statement covering every AI system in the company does not meet the intent of the standard, and it does not actually manage risk either. A model that recommends product bundles carries a very different risk profile than one that influences a hiring decision or a credit decision. 42001 expects the risk assessment to reflect that difference: what happens if this specific model is wrong, who is affected, and what controls exist to catch it before it causes harm.

    Monitoring Is the Part Most Programs Skip

    A model approved a year ago, on the data available a year ago, is not the same model running today if the underlying data has shifted, or if the vendor has quietly updated the model behind the scenes. Ongoing monitoring, not a one-time approval, is what the standard actually requires: a defined way to catch when a model’s behavior drifts from what was originally assessed and approved, and a process for re-review when it does.

    What Certification Readiness Actually Looks Like

    Getting ready for a 42001 assessment is less about writing new policy and more about building the evidence trail: the use case inventory, the risk assessments tied to each entry in it, the approval records, and the monitoring logs that show the system is a living process rather than a document that was signed once. That is the gap between organizations that pass and organizations that need another cycle: not effort, but evidence.

    If you are trying to figure out how far your current AI governance approach is from what an assessor would actually want to see, that is exactly the kind of independent review our AI Assurance & Responsible AI team runs.

  • ISO/IEC 42001 Is Not a Policy Document

    When a board asks for “an AI governance policy,” what often gets produced is a document: a few pages describing principles like fairness, transparency, and accountability, circulated for sign-off, then filed away until the next audit. It satisfies the request on paper. It does very little to actually manage the risk of an AI system making a bad decision in production.

    ISO/IEC 42001, the international standard for AI management systems, asks for something different. Not a statement of intent, but a system: a defined process for how AI use cases get identified, assessed for risk, approved, monitored, and improved, with evidence that the process is actually being followed.

    Use Case Inventory Comes Before Anything Else

    You cannot govern what you have not inventoried. A surprising number of organizations, when asked directly, cannot produce a complete list of where AI or machine learning is actually being used across the business. A model embedded in a vendor product counts. An internal tool a team built to triage support tickets counts. A generative AI assistant employees are using informally, without an approved workflow, counts too, and is often the largest source of unmanaged risk.

    The starting point under 42001 is a real inventory: every AI use case, who owns it, what data it touches, and what decision it influences. That inventory is what everything else in the standard hangs off of.

    Risk Review Has to Be Specific to Each Use Case

    A single generic risk statement covering every AI system in the company does not meet the intent of the standard, and it does not actually manage risk either. A model that recommends product bundles carries a very different risk profile than one that influences a hiring decision or a credit decision. 42001 expects the risk assessment to reflect that difference: what happens if this specific model is wrong, who is affected, and what controls exist to catch it before it causes harm.

    Monitoring Is the Part Most Programs Skip

    A model approved a year ago, on the data available a year ago, is not the same model running today if the underlying data has shifted, or if the vendor has quietly updated the model behind the scenes. Ongoing monitoring, not a one-time approval, is what the standard actually requires: a defined way to catch when a model’s behavior drifts from what was originally assessed and approved, and a process for re-review when it does.

    What Certification Readiness Actually Looks Like

    Getting ready for a 42001 assessment is less about writing new policy and more about building the evidence trail: the use case inventory, the risk assessments tied to each entry in it, the approval records, and the monitoring logs that show the system is a living process rather than a document that was signed once. That is the gap between organizations that pass and organizations that need another cycle: not effort, but evidence.

    If you are trying to figure out how far your current AI governance approach is from what an assessor would actually want to see, that is exactly the kind of independent review our AI Assurance & Responsible AI team runs.

  • Why Technology Due Diligence Needs Someone Who Is Not in the Deal

    By the time a target company’s technology stack reaches a private equity sponsor’s desk, it has usually already been through a round of polishing. The architecture diagram is current. The pitch deck describes a modern, cloud-native platform. What that picture often leaves out is not deception. It is the normal accumulation of shortcuts a growing company takes under deadline pressure, none of which show up cleanly in a slide.

    Sellers Describe the System They Wish They Had

    This is not usually intentional. A founder or CTO genuinely believes the architecture is sound because they remember designing it that way. What they do not always track closely is how much has drifted since: the integration that was supposed to be temporary and is now load-bearing, the database migration that got 80 percent finished before priorities shifted, the security control that was implemented for one product line but never extended to the others after an acquisition.

    A reviewer with a stake in getting the deal done, whether that is the seller’s own team or an integrator who wants the follow-on implementation work, has a natural incentive to describe the system in its best light. That is not a criticism of their honesty. It is simply what happens when the person assessing a system also has a reason to want it to look good.

    The Questions an Outside Reviewer Actually Asks

    An independent technical reviewer with no stake in whether the deal closes asks different questions than a sales-oriented walkthrough does. Not “does this architecture make sense,” but “show me the last three production incidents and what actually caused them.” Not “is the code well organized,” but “how much of this is one engineer’s undocumented knowledge, and what happens if they leave in month two of the hold period.”

    Those questions surface the kind of technical debt that does not show up in an architecture diagram: brittle integrations, scaling limits the team has quietly worked around rather than fixed, and security gaps that were accepted as a known risk years ago and never revisited.

    What This Changes for the Deal Itself

    A clear-eyed technology review before close does not usually kill deals. What it does is change the terms: a lower valuation that reflects real remediation cost, a holdback tied to specific fixes, or simply a hundred-day plan that starts with the right priorities instead of discovering them six months into the hold period, after the sponsor’s own team has already taken ownership.

    That is the role we play. We are not the integrator hoping to win the next phase of work, and we are not the seller’s team explaining their own decisions. We are an independent technical opinion, built on evidence the sponsor can act on, delivered before the wire goes out rather than after.

  • Why Technology Due Diligence Needs Someone Who Is Not in the Deal

    By the time a target company’s technology stack reaches a private equity sponsor’s desk, it has usually already been through a round of polishing. The architecture diagram is current. The pitch deck describes a modern, cloud-native platform. What that picture often leaves out is not deception. It is the normal accumulation of shortcuts a growing company takes under deadline pressure, none of which show up cleanly in a slide.

    Sellers Describe the System They Wish They Had

    This is not usually intentional. A founder or CTO genuinely believes the architecture is sound because they remember designing it that way. What they do not always track closely is how much has drifted since: the integration that was supposed to be temporary and is now load-bearing, the database migration that got 80 percent finished before priorities shifted, the security control that was implemented for one product line but never extended to the others after an acquisition.

    A reviewer with a stake in getting the deal done, whether that is the seller’s own team or an integrator who wants the follow-on implementation work, has a natural incentive to describe the system in its best light. That is not a criticism of their honesty. It is simply what happens when the person assessing a system also has a reason to want it to look good.

    The Questions an Outside Reviewer Actually Asks

    An independent technical reviewer with no stake in whether the deal closes asks different questions than a sales-oriented walkthrough does. Not “does this architecture make sense,” but “show me the last three production incidents and what actually caused them.” Not “is the code well organized,” but “how much of this is one engineer’s undocumented knowledge, and what happens if they leave in month two of the hold period.”

    Those questions surface the kind of technical debt that does not show up in an architecture diagram: brittle integrations, scaling limits the team has quietly worked around rather than fixed, and security gaps that were accepted as a known risk years ago and never revisited.

    What This Changes for the Deal Itself

    A clear-eyed technology review before close does not usually kill deals. What it does is change the terms: a lower valuation that reflects real remediation cost, a holdback tied to specific fixes, or simply a hundred-day plan that starts with the right priorities instead of discovering them six months into the hold period, after the sponsor’s own team has already taken ownership.

    That is the role we play. We are not the integrator hoping to win the next phase of work, and we are not the seller’s team explaining their own decisions. We are an independent technical opinion, built on evidence the sponsor can act on, delivered before the wire goes out rather than after.

  • What Actually Makes a CMMC Assessor Say No

    Most defense contractors we talk to are not starting from zero. They have a system security plan. They have policies. Someone has already walked through the NIST SP 800-171 requirements at least once. So when an assessment stalls or a self-assessment score comes in lower than expected, it is rarely because a control was never attempted. It is because the control exists on paper but was never tested against real evidence.

    Here are the gaps we run into most often, in the order they tend to surface during a readiness review.

    The System Security Plan Describes the Network You Meant to Build

    An SSP is a snapshot, and networks change faster than documentation does. A new cloud service gets added, a legacy server gets decommissioned late, or a contractor brings in a personal device for a two-week sprint, and the SSP is not updated to match. An assessor is not grading the document. They are grading whether the document matches what is actually running, and a mismatch here is one of the fastest ways to lose confidence in everything else in the package.

    The fix is not a bigger document. It is a habit: every time the environment changes in a way that touches CUI, the SSP gets a same-week update, not a pre-assessment scramble.

    Access Control Policies Exist, But Access Reviews Do Not

    Almost every organization we assess has a written access control policy. Far fewer can produce evidence that access was actually reviewed on a schedule. Someone left the company eight months ago and their account is still active. A shared service account has admin rights nobody remembers granting. The policy said this would be reviewed quarterly, but the last review anyone can point to was during initial rollout.

    CMMC assessors ask for evidence, not intent. A signed policy proves you planned to do something. A dated access review log, with names of who reviewed it and what changed, proves you did it.

    Incident Response Has Never Actually Been Tested

    The incident response plan is often one of the most polished documents in the package, and one of the least exercised. Nobody has run a tabletop. Nobody can say, with confidence, who gets called first if CUI is potentially exposed at 6 p.m. on a Friday. A plan that has never been tested is a plan you are hoping works, not one you know works, and that distinction matters to an assessor evaluating whether your organization can actually execute under pressure.

    Where This Leaves You

    None of this requires a bigger budget or a longer timeline. It requires an honest look at which of your controls are backed by dated, specific evidence and which are backed by a policy that was written once and never revisited. That is the review we run before a formal assessment: not another policy rewrite, but a evidence-first walk through what a C3PAO assessor will actually ask to see.

    If you want a second set of eyes on where your own package would hold up, our CMMC Readiness & RPO Advisory team can walk through it with you before an assessor does.