The vocabulary, in plain words
Every term carries what it is and why a practitioner cares. The second line is the part that makes it usable. Free at every tier, because vocabulary is the first barrier into this work and the wrong thing to charge for.
A B C D E F G H I J K L M N O P Q R S T V W Z
A
- Access Certification Effectiveness
-
Access certification is the periodic process of reviewing active accounts and their permissions and making deliberate decisions about whether each account should retain its current access , confirming that access is still appropriate, reducing scope where it has become disproportionate, and revoking access that is no longer needed.
access certification effectiveness matters for TPRM because access certifications are frequently cited as a primary governance control for vendor access management , evidence that access is periodically reviewed and confirmed as appropriate.
- Access Certification Effectiveness: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: most recent certification revocation rate , not just completion rate; bulk approval prevention confirmation in certification platform; certification quality monitoring description , review time adequacy and decision distribution.
- Access Policy Misconfigurations
-
Access policy misconfigurations are access control settings that do not correctly reflect the intended access model for a system, resource, or data at the current point in time.
access policy misconfigurations matter for TPRM because vendors who hold customer data may have storage, database, and application access policies that were correctly configured for the original sensitivity of that data but have not been updated as the data evolved.
- Access Policy Misconfigurations: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: CSPM tool and most recent scan findings; data reclassification to policy review linkage process; access policy review cadence documentation.
- Access reviews
-
An access review is a periodic check that the people who have access to a system still need it, performed by someone competent to judge, over a population you can show is complete, with revocations tracked to completion. It is the most commonly failed control in assurance work, and it fails in an unusual way: the review happens and it still does not pass.
every framework requires it, every auditor samples it, and the four ways it fails are consistent. The population was one system's export and missed the groups, the service accounts and the vendor support path. The reviewer approved forty entitlement names they could not read. Nothing was revoked, which after several cycles means nobody engaged. And decisions were recorded while removals were never verified.
- Accountability
-
GDPR Article 5(2) requires the controller to be responsible for, and able to demonstrate compliance with, the data protection principles. Accountability is not one more principle among the seven; it is the obligation to prove the other six. Documentation, records, assessments and policies are how that proof is constructed.
it is why documentation is an obligation rather than good practice. An organization that processes data lawfully but cannot show its reasoning has failed the accountability principle even if every other principle was met. Undocumented good behaviour scores poorly in an investigation because the investigator cannot distinguish it from luck.
- Adequacy decisions
-
An adequacy decision is a finding by the European Commission that a third country provides a level of data protection essentially equivalent to the EU's, allowing personal data to flow there without any further transfer mechanism. The UK, Japan, Switzerland, Canada for commercial organizations, and the United States under the Data Privacy Framework are among those covered.
adequacy is convenient and conditional. Safe Harbour was invalidated in 2015. Privacy Shield was invalidated in 2020. Each time, transfers relying on the decision lost their mechanism overnight and organizations scrambled for SCCs. The Data Privacy Framework has already faced challenge, and the UK decision has a sunset clause requiring renewal.
- AI Adversarial Attacks
-
Adversarial attacks matter for TPRM because the AI models that vendors deploy for consequential decisions , document authentication, identity verification, fraud detection, quality control , may have adversarial vulnerabilities that standard benchmark accuracy metrics do not reveal.
adversarial attacks matter for TPRM because the AI models that vendors deploy for consequential decisions , document authentication, identity verification, fraud detection, quality control , may have adversarial vulnerabilities that standard benchmark accuracy metrics do not reveal.
- AI Adversarial Attacks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: attack types tested , white-box, black-box, transfer; a vendor who confirms 97% benchmark accuracy should be asked about adversarial robustness. Benchmark accuracy describes performance on standard test data. Adversarial robustness describes performance on inputs specifically designed to exploit the model. Both measure performance. They measure different things.
- AI API Key Exposure
-
AI API key exposure is the security risk created when credentials that authenticate access to AI model APIs , keys issued by AI vendor developer portals, inference endpoints, and model serving infrastructure , are generated, managed, stored, and used outside the enterprise's established credential management programme.
AI API key exposure matters for TPRM because the enterprise's AI vendor relationships , increasingly numerous as AI is embedded across business functions , generate a growing population of credentials that authenticate access to sensitive AI capabilities and may expose the vendor's model to the enterprise's query patterns and data.
- AI API Key Exposure: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: active API key inventory for the organization; permission scope for each issued key; anomalous key usage alerting capability.
- AI Attack Surface Expansion
-
AI attack surface expansion is the growth in an enterprise's aggregate data exposure and system vulnerability that occurs as multiple AI vendors and tools are adopted over time , each individually assessed as acceptable risk, but collectively creating a risk surface that is greater than the sum of the individual assessments.
AI attack surface expansion matters for TPRM because the enterprise that evaluates AI vendors in isolation may miss the aggregate risk created by multiple AI vendors collectively accessing different elements of the same data universe.
- AI Attack Surface Expansion: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: individual data access scope documentation; awareness of aggregate exposure context; a vendor who confirms appropriate data access scoping should be asked about aggregate exposure awareness. Individual scoping is appropriate for individual access. Aggregate exposure requires the combined view that individual assessments do not produce.
- AI Bias in Risk Decisions
-
AI bias in risk decisions is the systematic distortion of AI-generated risk assessments caused by biases encoded in training data, model design choices, or feedback loops created when AI outputs influence future training data.
AI bias in risk decisions matters for TPRM because AI-powered vendor risk scoring increasingly drives material decisions about vendor relationships , due diligence depth, contract terms, monitoring intensity, and vendor tiering.
- AI Bias in Risk Decisions: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: training data assessment intensity analysis; disparate impact assessment across vendor groups; a vendor who confirms AI objectivity should be asked about accuracy across characteristic groups. Objectivity confirms consistency. Accuracy across groups confirms the consistency reflects genuine risk rather than historical assessment patterns.
- AI Compliance Enforcement
-
AI compliance enforcement is the operational capability to ensure that AI governance policies , review requirements, deployment standards, monitoring obligations , are actually applied to all AI systems that fall within the policy's scope, not just the systems that are presented for review through expected channels.
AI compliance enforcement matters for TPRM because vendors who claim comprehensive AI governance should be assessed on enforcement coverage , what fraction of their AI deployments are actually reviewed through their governance process , not just on the governance process itself.
- AI Compliance Enforcement: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: AI inventory with reviewed vs total discovered systems; saaS procurement AI review integration; a vendor who confirms AI governance process should be asked for enforcement coverage. Process confirms the governance mechanism. Coverage ratio confirms how much of the AI estate the mechanism actually reaches.
- AI Compliance vs Security Gap
-
The AI compliance versus security gap is the distinction between an AI system's compliance with general data protection and security regulations , GDPR for data handling, SOC 2 for security controls, ISO 27001 for information security management , and its compliance with the specific requirements that apply to AI systems making consequent
the AI compliance versus security gap matters for TPRM because the enterprise that deploys a vendor's AI system in a regulated use case inherits the compliance obligations of that use case , regardless of whether the vendor's compliance documentation covers those obligations.
- AI Compliance vs Security Gap: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: article 22 individual explanation example; EU AI Act high-risk assessment; a vendor who confirms GDPR compliance should be asked for the Article 22 explanation example. GDPR compliance covers data handling. Article 22 compliance covers automated decision-making. The same regulation, different obligations.
- AI Continuity and Exit Planning
-
AI continuity and exit planning is the set of practices that ensure an enterprise can maintain business continuity when an AI vendor model is sunset, a vendor exits the market, or a commercial relationship must be terminated , specifically including the preservation of training data, the documentation of model calibration and feature engi
AI continuity and exit planning matters for TPRM because the operational dependency on AI models creates business continuity risk that is not addressed by standard business continuity planning.
- AI Continuity and Exit Planning: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: transition assistance commitment , training data and feature engineering; data portability in reusable format; a vendor who confirms strong AI model performance should be asked about sunset notice and transition assistance. Performance confirms the value of the dependency. Sunset notice and transition assistance determine the cost of unwinding it under time pressure.
- AI Data Lineage Issues
-
AI data lineage in the security operations context describes the complete path that security signals, alerts, and intelligence travel from their point of generation by AI detection systems through the workflow, prioritisation, escalation, and response processes that determine how and when humans act on them.
AI data lineage in security operations matters for TPRM because the security outcome of a vendor's AI security monitoring deployment depends on the complete path from detection to response , not just the AI's detection capability.
- AI Data Lineage Issues: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: expected detection-to-investigation time for after-hours critical alerts; mean time to investigate as a tracked metric; after-hours escalation process for critical AI alerts.
- AI Data Retention Risks
-
AI data retention risks are the security, compliance, and legal risks arising from the retention of data that users input to AI systems , specifically the risk that sensitive, regulated, or legally protected information uploaded to an AI assistant, submitted as an AI query, or processed by an AI pipeline is retained on the AI vendor's or
AI data retention risks matter for TPRM because the informal and rapid adoption of AI tools in enterprise environments creates systematic retention risk for sensitive data categories , MNPI, personal data, legally privileged information, regulated health data , that individual employees upload to AI assistants without specific awareness o
- AI Data Retention Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: vendor-level retention period for current tier; LLM provider retention period disclosure; DPA commitment to zero or configurable retention.
- AI Explainability Challenges
-
AI explainability challenges matter for TPRM because the legal and regulatory requirements for AI explanation are significantly more demanding than what current explainability tools automatically provide.
AI explainability challenges matter for TPRM because the legal and regulatory requirements for AI explanation are significantly more demanding than what current explainability tools automatically provide.
- AI Explainability Challenges: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: complete plain-language explanation example for affected individual; feature legitimacy documentation for high-contributing features; regulatory explanation standard compliance assessment.
- AI governance
-
AI governance is the set of decisions, owners and records that determine what AI systems an organization uses, what each decides and about whom, who approved it, and what oversight exists. It is distinct from AI safety, which concerns the behaviour of models themselves, and from model security, which concerns attacks on them. Governance is about the organization's use.
ask an organization how many AI systems it uses and the answer is wrong by an order of magnitude. It counts the two models the data team built and misses the vendor feature scoring support tickets, the recruiting tool ranking candidates, and the assistant embedded in a product nobody thought of as adopting AI. Governance starts with knowing what is in use, and most programmes start somewhere else.
- AI Governance Frameworks
-
AI governance framework gaps are the differences between documented AI governance processes and their operational implementation , the committee meetings that do not occur at the stated frequency, the model reviews that are conducted for initial deployment and skipped for subsequent updates, and the monitoring programmes that are describe
AI governance framework gaps matter for TPRM because governance documentation confirms the vendor's intent.
- AI Governance Frameworks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: last three AI Ethics Committee meeting minutes; model review records for most recent model updates; model validation applicability to updates confirmation.
- AI Governance Gaps
-
AI governance gaps are the deficiencies in an organization's AI governance framework , policies, processes, review committees, and compliance frameworks , that result in AI systems being deployed or continuing to operate without adequate oversight, transparency, or compliance with applicable regulatory requirements.
AI governance gaps matter for TPRM because the enterprise's regulatory compliance obligations apply to vendor AI systems that perform regulated functions in the enterprise's workflows , regardless of whether those systems were procured rather than internally developed.
- AI Governance Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: EU AI Act high-risk assessment for applicable systems; a vendor who confirms AI governance maturity should be asked about current regulatory alignment. Governance maturity describes the framework. Regulatory currency describes whether the framework reflects the regulations that currently apply.
- AI Hallucination Risk in Decisions
-
In the context of consequential AI decision-making, hallucination risk extends beyond LLM confabulation to encompass the broader category of confident AI decisions based on patterns that do not reflect sound, legally defensible, or ethically appropriate reasoning.
AI hallucination risk in decisions matters for TPRM because the enterprise that deploys a vendor's consequential decision AI inherits the model's decision rationale , and the legal, regulatory, and reputational consequences if that rationale is found to be discriminatory, arbitrary, or legally indefensible.
- AI Hallucination Risk in Decisions: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: a vendor who confirms explainability should be asked for the plain-language explanation example and proxy discrimination assessment. Technical explainability identifies what the model used. Meaningful explainability connects what it used to why that is a legitimate reason.
- AI impact assessments
-
An AI impact assessment establishes, for a system that matters, what it decides and about whom, what could go wrong for a person rather than for the company, how it is classified under applicable law, and what oversight and monitoring will exist before it goes live. Its output is decisions, not a document, and it is closely related to a data protection impact assessment, which it often accompanies.
assessments arrive in two unhelpful shapes. A security questionnaire with the word AI added, asking about encryption while saying nothing about who the system decides against. Or a philosophical document about fairness that changes nothing. The useful assessment sits between them and asks the two questions that shape everything: what does it decide, and about whom.
- AI Incident Response Gaps
-
AI incident response gaps are the deficiencies in an organization's incident response programme that leave AI model decision incidents , harmful AI decisions, AI model failures, AI system manipulation, and AI governance violations , without defined investigation procedures, evidence preservation requirements, escalation paths, or remediat
AI incident response gaps matter for TPRM because vendor AI products that make consequential decisions , credit, insurance, employment, clinical , will eventually produce decisions that are disputed, investigated, or litigated.
- AI Incident Response Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: AI incident playbook or equivalent; external AI expertise escalation path; a vendor who confirms comprehensive IR capability should be asked for their AI incident playbook. Traditional IR covers cybersecurity incidents. AI incident response covers model decision incidents. Both are required for enterprise AI deployments.
- AI Inference Data Leakage
-
AI inference data leakage is the exposure of data that is present in an AI model's inference environment , the context window, the retrieval-augmented system prompt, connected data sources loaded as context, and the model's intermediate processing states , to extraction through user inputs, prompt manipulation, or side-channel techniques
AI inference data leakage matters for TPRM because zero-retention configuration , while necessary , is not sufficient to protect sensitive data that passes through the AI inference environment.
- AI Inference Data Leakage: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: context window content description , what is loaded at session start; in-session prompt injection test results for context extraction; system prompt confidentiality test results.
- AI Logging and Traceability
-
AI logging and traceability is the comprehensive capture of the information required to reconstruct an AI system's decision at any point after the decision was made , specifically the model version that made the decision, the input data that was presented to the model at decision time, the model's intermediate outputs, and the final decis
AI logging and traceability matters for TPRM because regulatory examinations, litigation, and individual decision appeals all require the ability to reconstruct specific AI decisions from historical records.
- AI Logging and Traceability: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: historical decision audit trail demonstration; point-in-time input feature logging confirmation; retention period for decision logs.
- AI Misuse by Vendors
-
AI misuse by vendors encompasses the ways that vendor-deployed AI systems produce harmful, inequitable, or operationally incorrect outcomes through training data biases, model design choices, and deployment contexts that cause the AI to systematically disadvantage specific customer segments.
AI misuse by vendors matters for TPRM because the enterprise's customers interact with the vendor's AI-powered systems, and the outcomes those systems produce , support prioritisation, service classification, response routing , affect the enterprise's customers, not just the vendor's.
- AI Misuse by Vendors: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: fairness audit results across customer segments; a vendor who confirms strong AI performance should be asked for segment-specific metrics. Average performance confirms the system works for the average. Segment-specific metrics reveal whether it works consistently for everyone.
- AI Misuse Scenarios
-
AI misuse scenarios in the enterprise context are situations where AI tools approved and deployed for legitimate business purposes are used , or use themselves autonomously , in ways that create legal, ethical, or reputational risk that was not assessed during the approval process.
AI misuse scenarios matter for TPRM because vendor AI tools approved for legitimate functions may have capabilities , autonomous data gathering, automated decision-making, scale processing , that create legal and ethical risks not visible in the security assessment that focused on how the tool handles user-provided data.
- AI Misuse Scenarios: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: autonomous data gathering capability disclosure; GDPR legal basis for external data processing; transparency requirement guidance for users.
- AI Model Supply Chain Risk
-
AI model supply chain risk is the category of risks that arise from the provenance, composition, and integrity of the components that go into an AI model , specifically the training data, the base model architecture, the fine-tuning process, and the infrastructure used to develop and deploy the model.
AI model supply chain risk matters for TPRM because the AI products that vendors are now integrating into enterprise workflows are not traditional software , they carry information about the data they were trained on, they can behave in unexpected ways when inputs trigger embedded biases or backdoors, and their risk profile depends on a s
- AI Model Supply Chain Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: training data opt-out confirmation and controls; an AI vendor who provides a SOC 2 report should also be asked for model card documentation, training data provenance, and inference attack assessment. The SOC 2 covers the operational wrapper. The model documentation covers the supply chain risk inside it.
- AI Model Version Control
-
AI model version control risk encompasses the security and operational risks that arise from the management of AI model versions in production , specifically the risks created when foundation model updates, security patches, and model revisions are delayed, inconsistently applied, or not tracked with the same rigour as traditional softwar
AI model version control matters for TPRM because the AI products that vendors deploy in enterprise environments are built on dependency chains , foundation models, serving infrastructure, ML frameworks , that require ongoing security patching.
- AI Model Version Control: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: current deployed foundation model version vs latest available; security patch currency , pending patches and their security classification; fast-track validation process for security patches.
- AI Operational Risks
-
AI operational risks are the risks that arise from deploying AI systems in real-world operational contexts where the model's performance characteristics , accuracy, failure modes, confidence levels, and systematic biases , interact with business process assumptions, human oversight levels, and downstream consequence in ways that create op
AI operational risks matter for TPRM because the business processes that depend on vendor AI products are typically designed around aggregate accuracy metrics rather than systematic error patterns.
- AI Operational Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: segmented accuracy reporting by case type or complexity; business process assumption validation against error pattern; human review scope coverage of high-miss segments.
- AI Output Data Leakage
-
AI output data leakage in the context of enterprise AI products encompasses two distinct risk dimensions. The first is the traditional sense of data leakage , sensitive data from the AI's context, training corpus, or connected knowledge base appearing in outputs that are accessible to unauthorised parties.
AI output data leakage matters for TPRM because the AI products that vendors deploy for enterprise knowledge workers , research assistants, document drafters, customer communication tools, analysis accelerators , create systematic confabulation risk in the outputs those workers produce.
- AI Output Data Leakage: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: confabulation rate assessment in relevant domain; a vendor who confirms AI research assistance quality should be asked about confabulation rate assessment and source attribution. Output quality confirms the generation process works. Confabulation rate assessment confirms how often what it generates is accurate.
- AI Plugin Vulnerabilities
-
AI plugin vulnerabilities in the context of AI-powered security tools are the structural blind spots and operational limitations of machine learning-based detection systems , not failures in the technology's implementation, but inherent constraints of how supervised machine learning works that create systematic gaps between published dete
AI security plugin vulnerabilities matter for TPRM because AI-based security monitoring is increasingly positioned as the primary detection layer , replacing or significantly reducing human analyst review.
- AI Plugin Vulnerabilities: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: test dataset technique coverage scope; LOTL and adversarial evasion coverage confirmation; production false positive rate at comparable enterprises.
- AI Risk Scoring Reliability
-
AI risk scoring reliability is the degree to which an AI-generated risk score accurately predicts the risk it claims to measure , and the availability of the metadata, calibration data, and uncertainty quantification that allow risk practitioners to assess whether the score should be trusted for the specific decision it is being used to s
AI risk scoring reliability matters for TPRM because risk scores that are treated as reliable when they are not calibrated, confidence-quantified, or trend-tracked produce systematically incorrect resource allocation , too much attention on high-scoring vendors who are not actually high-risk, too little on low-scoring vendors who are actu
- AI Risk Scoring Reliability: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: calibration data by score range; confidence interval or uncertainty quantification; historical score trend , minimum six months.
- AI Security Monitoring
-
Comprehensive AI security monitoring requires not just that the monitoring programme reports on what it detects, but that it provides an honest accounting of what it does not detect, where its detection confidence is lower, and what human analyst activities are necessary to compensate for the AI's limitations.
comprehensive AI security monitoring matters for TPRM because the security assurance that monitoring reports provide depends on those reports accurately representing both the programme's capabilities and its limitations.
- AI Security Monitoring: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: coverage gap disclosure in monitoring reports; confidence variation disclosure by alert category; a vendor who provides weekly AI monitoring reports should be asked to add a limitations section. Performance metrics describe what is working. Limitation disclosure describes what the performance metrics do not show. Both are required for an honest security monitoring report.
- AI Security Testing Gaps
-
AI security testing gaps are the omissions in a vendor's security testing programme that leave the AI model itself , as distinct from the infrastructure, application, and operational controls around it , untested against the specific attack categories that AI systems are vulnerable to.
AI security testing gaps matter for TPRM because the security assurance evidence that vendors provide for AI products often covers the traditional security dimensions comprehensively while leaving the AI-specific security dimensions completely unassessed.
- AI Security Testing Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: AI-specific security testing evidence , adversarial inputs, prompt injection; AI red team exercise results; a vendor who provides SOC 2, penetration testing, and SDLC evidence should be asked for AI-specific testing evidence as a separate category. Traditional evidence covers the wrapper. AI testing covers the model. Both are needed.
- AI Supply Chain Dependencies
-
AI supply chain dependencies are the open-source libraries, pre-trained model components, data processing utilities, and ML framework packages that constitute the software stack on which an AI system is built , and through which supply chain attacks can compromise the AI system without attacking the model itself.
AI supply chain dependencies matter for TPRM because the vendor's AI system's security is bounded by the security of every component in its dependency stack , not just the model architecture and the training process.
- AI Supply Chain Dependencies: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: AI pipeline SBOM with all ML dependencies; SCA tool coverage for all AI dependencies; model serialisation format and safe loading confirmation.
- AI Threat Detection Gaps
-
AI threat detection gaps are the technique categories, attack patterns, and threat actor behaviours that an AI-powered security monitoring platform does not detect , either because detection coverage for those categories was never configured, because the AI's training data did not include representative examples of those techniques, or be
AI threat detection gaps matter for TPRM because all-green detection dashboards are frequently presented as evidence of comprehensive coverage , and accepted as such by TPRM teams reviewing vendor security posture.
- AI Threat Detection Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: intelligence-to-configuration timeline for recent advisories; ATT&CK coverage map updated in last quarter; active detection confirmation for specific ISAC-advised techniques.
- AI vendor assessment
-
Assessing a vendor whose product includes AI adds questions the standard security review does not ask. What does the system decide, and about whom. What data was it trained on, at a level of description the vendor will commit to. What performance information do they publish, and for which populations. What oversight does the product support, and what logging can you access. Answers you cannot get are findings.
almost all AI arrives inside vendor products, so most organizations are assessing someone else's model with limited visibility. The standard questionnaire establishes whether the vendor encrypts data and reviews access. It does not establish whether the recruiting tool's ranking was ever measured on candidates over fifty, and that is the question the regulator will ask you, not the vendor.
- AI Vendor Lock-In Risks
-
AI vendor lock-in risks arise when an enterprise's operational dependency on a specific vendor's AI model becomes so deep that switching costs , in time, recalibration effort, workflow redesign, and operational disruption , are prohibitively high.
AI vendor lock-in matters for TPRM because deep AI dependencies create concentration risk that may not be visible until a disruption forces migration.
- AI Vendor Lock-In Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: contractual API deprecation notice period; a vendor who confirms strong AI performance should be asked about their deprecation notice period and migration assistance. Performance confirms the value of the dependency. Migration assistance and notice period determine the cost of unwinding it.
- AI-Assisted Code Review Security Risks
-
AI code generation security matters for TPRM because the adoption of AI coding assistants in vendor development workflows may be introducing vulnerability patterns that existing security tooling is not optimally configured to detect.
AI code generation security matters for TPRM because the adoption of AI coding assistants in vendor development workflows may be introducing vulnerability patterns that existing security tooling is not optimally configured to detect.
- AI-Assisted Code Review Security Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: AI coding assistant adoption disclosure and governance; SAST coverage assessment for AI-generated patterns; finding rate change monitoring since adoption.
- AI-Driven Automation Risks
-
AI-driven automation risks are the operational, legal, and reputational consequences that arise when autonomous AI workflows execute decisions and actions at scale without adequate integration with the full operational context, without appropriate human oversight of boundary cases, and without constraints that limit autonomous action to s
AI-driven automation risks matter for TPRM because vendors who use AI automation in workflows that affect the enterprise , contract management, customer communications, billing, compliance reporting , can produce bulk operational errors that affect the enterprise's customers, partners, and regulatory relationships.
- AI-Driven Automation Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: pre-execution review for bulk communications; a vendor who confirms AI automation performance should be asked about data integration completeness and pre-execution review. Performance metrics reflect what the automation does correctly within its scope. Integration completeness and review gates constrain what it does incorrectly at scale.
- Alert Fatigue Across Ecosystems
-
Alert fatigue is the degradation in analysis quality that results from high alert volumes overwhelming the analytical capacity available per alert.
alert fatigue matters for TPRM because vendor SOC quality is the customer's protection against threats to their data , and SOC quality under high alert volume conditions is significantly lower than SOC quality under managed alert volume conditions.
- Alert Fatigue Across Ecosystems: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: alert volume per analyst per shift; false positive rate by alert category; SOAR automation deployment and alert volume impact.
- Alert Prioritisation Gaps
-
Alert prioritisation gaps are the misalignments between static alert severity assignments and the dynamic risk context that makes specific techniques more or less dangerous depending on the current threat landscape. Alert severity levels are assigned when rules are written based on the technique's general risk profile at that time.
alert prioritisation gaps matter for TPRM because the SOC's response speed to a specific alert is determined by its severity level , and a severity level that does not reflect current threat context produces response speeds that are calibrated for a threat landscape that no longer exists.
- Alert Prioritisation Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: threat intelligence to prioritisation pipeline confirmation; recent severity update triggered by threat intelligence; a vendor who confirms defined alert SLAs should be asked whether the severity assignments routing alerts into those SLAs are updated based on current threat intelligence. The SLAs measure compliance. The severity assignments determine whether compliance is calibrated to the current threat.
- Algorithmic bias testing
-
Bias testing measures whether a system's outputs differ across groups of people in ways that matter, for example whether error rates, approval rates or scores vary by a protected characteristic or by a proxy for one. Nobody has to intend the difference for it to exist. A model trained on historical decisions learns the patterns in those decisions, including the ones nobody would defend.
it is the measurement most assessments claim and few perform. Performance measured in aggregate can be excellent while performance for one group is poor, and aggregate figures hide exactly the finding a regulator or a claimant will bring. The EU AI Act's obligations for high-risk systems, and the NIST framework's Measure function, both assume you can produce the numbers by group.
- Anonymisation techniques
-
Anonymisation techniques include aggregation, which reports totals rather than individuals; generalisation, which replaces precise values with ranges; suppression, which removes rare values; noise addition, which perturbs values; and differential privacy, which bounds what any query can reveal about any individual. Each reduces re-identification risk differently and at a different cost in utility.
the legal test is whether re-identification is reasonably likely by any means, including combination with other datasets. A dataset that looks anonymous in isolation can be re-identified by joining it with a voter roll, a social profile or a previous breach. The auxiliary data is what makes re-identification possible, and it is not under the controller's control.
- Answer library
-
The set of approved answers to recurring buyer security questions, each with its evidence, owner and review date.
Buyer questions repeat heavily. By the third questionnaire most have an approved answer and the work shifts from writing to reviewing.
Taught in TPR-260 · See also: Trust centre, Attestation
- API Authentication Weaknesses
-
API authentication is the set of mechanisms through which an API verifies that a requesting party is who they claim to be and is authorized to make the request they are making.
API authentication is the control that establishes the trust boundary between your organization and the vendor's platform.
- API Authentication Weaknesses: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: token expiry period and rotation process documentation , a timeframe and a process, not a policy statement; OAuth scope documentation specific to the integration , the actual scopes, not the available scopes; API penetration testing scope confirmation explicitly including authentication mechanism assessment.
- API Identity Misuse
-
API identities are the credentials , API keys, client secrets, OAuth tokens, and similar machine-readable authentication tokens , used by applications, integrations, and automated processes to authenticate to APIs and platforms.
API identity misuse matters for TPRM because API keys are the primary mechanism through which vendor applications and integration partners access customer platforms , and the lifecycle management of those keys determines whether the access they provide remains within its intended scope or outlasts and outgrows it.
- API Identity Misuse: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: API key inventory with last-use dates and application associations; repository scanning confirmation with last scan results; usage monitoring description , how unexpected key usage is detected.
- API Security Testing in CI/CD
-
API security testing matters for TPRM because the APIs that enterprise vendors expose for integrations , REST APIs, GraphQL endpoints, webhook receivers , are access points into the vendor's data and functionality that require API-specific security testing to assess effectively.
API security testing matters for TPRM because the APIs that enterprise vendors expose for integrations , REST APIs, GraphQL endpoints, webhook receivers , are access points into the vendor's data and functionality that require API-specific security testing to assess effectively.
- API Security Testing in CI/CD: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: API-specific security testing tool and coverage; BOLA test cases and multi-user testing approach; OWASP API Top 10 coverage documentation.
- API-Based AI Exposure
-
API-based AI exposure is the data and security risk created when a vendor's AI product uses a third-party LLM API , such as OpenAI's GPT-4, Anthropic's Claude, Google's Gemini, or Azure OpenAI , as its underlying inference engine, causing enterprise data submitted to the vendor's product to flow through the third-party LLM provider's infr
API-based AI exposure matters for TPRM because the rapid adoption of LLM-powered vendor products has created a new class of fourth-party risk that most TPRM programmes have not systematically addressed.
- API-Based AI Exposure: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: LLM backend disclosure , provider and service tier; DPA coverage of LLM provider data handling; enterprise tier subscription confirmation with enhanced terms.
- App Logging and Traceability
-
Application logging in a security context is the systematic capture of events that are relevant to security , events that enable detection of attacks in progress, investigation of incidents after the fact, and demonstration of compliance with access control and data handling obligations.
application logging in vendor environments is relevant to TPRM for two distinct reasons that are often conflated but have different governance implications.
- App Logging and Traceability: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: affirmative answer to the sixty-day scenario question with specific confirmation of data access logging and identity attribution capability; log retention policy documentation showing retention period and the requirement it is calibrated to; data access event logging confirmation at the application layer with user identity attribution.
- Artifact Registry Security
-
Artifact registry security matters for TPRM because the software artifacts your enterprise receives from vendors are distributed through registries whose security posture determines whether the artifact you download is the artifact the vendor published.
artifact registry security matters for TPRM because the software artifacts your enterprise receives from vendors are distributed through registries whose security posture determines whether the artifact you download is the artifact the vendor published.
- Artifact Registry Security: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: registry access review records and current account list; identity lifecycle integration for registry access; a vendor who confirms artifact signing should be asked about registry immutability and access controls. Signing confirms the artifact at publication. Immutability ensures the artifact at download is the artifact at publication. Access controls determine who can replace a mutable artifact.
- Assurance versus certification
-
A SOC 2 is an attestation: a CPA firm expresses an opinion on management's assertion about its controls, under an attestation standard. ISO 27001 is a certification: an accredited certification body certifies that a management system conforms to a published standard, following an audit against that standard's requirements. The words describe different mechanisms, different outputs and different regulators.
buyers ask for certification and receive an attestation, or the reverse, and neither party notices until a contract clause is tested. A SOC 2 cannot be renewed like a certificate; an ISO certificate does not contain tested controls like a report.
- Assurance vs Validation
-
Assurance is professional confidence, expressed by an independent third party, that a system of controls is operating in accordance with defined criteria based on evidence gathered through structured assessment methods.
assurance versus validation matters for TPRM because the specific risks that customer relationships create , the particular data they expose, the particular access patterns they enable, the particular attack scenarios that are most relevant , are frequently not within the criteria of the compliance frameworks that provide the primary assu
- Assurance vs Validation: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: confirmation of whether specific scenario was tested in existing assessments; consent to targeted validation testing for unvalidated scenarios; previous test results if scenario was assessed.
- Attack Dwell Time via Vendors
-
Attack dwell time via vendors matters for TPRM because the customer's data exposure begins not when the attacker enters the customer's environment but when the attacker gains access to any environment in the supply chain pathway to the customer's data.
attack dwell time via vendors matters for TPRM because the customer's data exposure begins not when the attacker enters the customer's environment but when the attacker gains access to any environment in the supply chain pathway to the customer's data.
- Attack Dwell Time via Vendors: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: empirical MTTD from actual incidents; detection source , internal SOC vs external notification; longest dwell time from recent incidents.
- Attestation
-
A statement an organization makes about itself, sometimes signed by an officer, as distinct from a certification issued by an external body.
Its credibility rests entirely on the discipline behind it, and an unsupportable claim fails three ways: with buyers, insurers and regulators.
Taught in TRS-210 · See also: Trust centre, Answer library
- Attestation and certification
-
A certification is issued by an accredited external body against a defined scheme, such as ISO 27001, after an audit, and it can be checked with the issuer. An attestation is a statement about yourself, sometimes signed by an officer and sometimes accompanied by an independent examination, as with a SOC 2 report, where an auditor attests to management's description. The words are used interchangeably in sales conversations and mean different things in a dispute.
buyers ask whether you are certified, and the honest answer for many strong programmes is that they hold an attestation report rather than a certificate. Insurers, regulators and enterprise procurement all read the distinction. Claiming certification when you hold an attestation is a misstatement, and it is one that a competent buyer catches in the first call.
- Audit Evidence Quality
-
Audit evidence quality is the degree to which evidence provided for a security control actually demonstrates what it is represented as demonstrating , that the control is implemented, operating effectively, and applied to all relevant systems and users, not just that a setting exists in a captured configuration at a particular time.
evidence quality matters for TPRM because the assurance provided by a completed assessment is only as strong as the evidence that supports it.
- Audit Evidence Quality: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: coverage confirmation , all roles confirmed or comprehensive policy screenshot; currency confirmation , evidence represents current state; automated compliance output preferred over manual screenshots.
- Audit Scope Limitations
-
Audit scope limitations are the boundaries of what an audit examined, tested, and concluded upon , and by implication, what the audit did not examine, test, or reach conclusions about.
audit scope limitations matter for TPRM because SOC 2 reports, ISO 27001 certificates, and other third-party audit reports are the primary evidence for control effectiveness in vendor assessments , and all of them have scope limitations that affect what the report's conclusions validly support.
- Audit Scope Limitations: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: disclosure of known control quality issues during the audit period; description of significant post-period changes; exceptions section and management's response from the most recent report.
- Auditor independence
-
The service auditor must be independent of the controls they examine. The attestation standards prohibit the auditor from designing, implementing or operating the controls, because an auditor who built the control cannot credibly opine on whether it works. Independence is a precondition of the opinion having any value.
it explains why your auditor will not write your policies, will not tell you exactly which control to implement, and will answer a question about remediation with a description of the criterion rather than a solution. A firm that offers both readiness consulting and the audit must keep the two in separate teams, and many refuse to do both for the same client.
- Automated decision-making
-
GDPR Article 22 gives individuals the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significant effects on them. Where such decisions are permitted, by contract, by law or by explicit consent, the individual has the right to human intervention, to express their view, and to contest the decision.
credit decisions, hiring screens, insurance pricing and fraud blocks increasingly involve models, and the human in the loop is often nominal. A reviewer who approves whatever the model recommends, at a rate of hundreds per day, is not intervening. The decision is solely automated in substance whatever the process diagram says.
B
- Backup testing
-
A backup is a copy. A restore is the proof that the copy can become a working system within the time you promised. Backup testing means performing the restore, on a schedule, to a defined target, verifying the result, and recording what happened. Most organizations run backups. Far fewer have ever restored one under anything like the conditions of a real failure.
backups are the control every framework asks about and every insurer asks about, and the assurance most organizations offer is that the backup job completed. A completed job proves the copy was written. It proves nothing about whether the copy is readable, complete, current, or restorable within the objective, and ransomware has made the difference between a backup and a restore into the difference between an outage and a closure.
- Branch Protection and Code Review Bypasses
-
Branch protection bypasses matter for TPRM because they represent the gap between the software supply chain controls a vendor has documented and the controls that are actually enforced in practice.
branch protection bypasses matter for TPRM because they represent the gap between the software supply chain controls a vendor has documented and the controls that are actually enforced in practice.
- Branch Protection and Code Review Bypasses: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: branch protection configuration including admin coverage; repository admin access list and last review date; audit log monitoring for direct commits to protected branches.
- Breach Attribution Challenges
-
Breach attribution is the process of determining who conducted a specific attack , the threat actor, their motivation, their organizational affiliation, and their likely next actions.
breach attribution challenges matter for TPRM because the customer's response to a vendor breach should not be paused waiting for definitive attribution from the vendor's forensic investigation.
- Breach Attribution Challenges: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: confirmed technical facts separate from attribution , access timeline, systems, data types; TTPs observed in the investigation regardless of attribution; preliminary scope assessment independent of attribution.
- Breach notification
-
GDPR requires a controller to notify the supervisory authority of a personal data breach within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals. Where the risk is high, affected individuals must also be told without undue delay. Processors must notify their controllers without undue delay.
awareness comes earlier than confirmation. Teams wait for a complete picture before notifying and miss the deadline, when the regulation explicitly allows notification in phases: an initial notification with what is known, followed by supplementary information as the investigation progresses. The 72 hours is for the first contact, not the final report.
- Breach Simulation Gaps
-
Breach simulation gaps are the differences between what a breach simulation exercise tests and what a real security incident requires , specifically the gap between a scripted, cooperative simulation where the IR team is informed of each step and a real breach where detection is ambiguous, scope is uncertain, the attacker is active and ad
breach simulation gaps matter for TPRM because the simulation report that confirms IR capability to defined criteria may be testing a different set of capabilities than a real breach requires.
- Breach Simulation Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: simulation methodology , scripted vs detection-first; purple team or live-fire exercise history; MTTD and MTTC from adversarial exercises.
- Bridge letter gap letter
-
A statement from a service organization covering the period between the end of its most recent assurance report and today.
It is management's representation, not an auditor's opinion: no controls were tested for that period. A bridge stretching past about six months usually means the next report is late.
Taught in TPR-210 · See also: Type I and Type II, Subservice organisation
- Bridge letters
-
A bridge letter, sometimes called a gap letter, covers the time between the end of a report's observation period and the date a customer is reading it. It asserts that no material changes to the control environment have occurred since the period ended. It is written and signed by the vendor's management.
reports are always historical. If the period ended in September and it is now February, five months are uncovered, and the bridge letter is the customary way to address that gap without waiting for the next report.
- Broken Access Control in Vendor Apps
-
Broken access control is the failure of an application to correctly enforce the rules that determine which authenticated users can access which resources, perform which actions, and see which data.
broken access control in a vendor application is uniquely dangerous from a third-party risk perspective because it can expose your organization's data to other customers on the same platform , and expose you to other customers' data in ways that create regulatory liability regardless of intent.
- Broken Access Control in Vendor Apps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: penetration test scope documentation explicitly including IDOR testing and privilege escalation scenarios; cross-tenant isolation testing confirmation for multi-tenant applications with evidence of methodology; server-side authorization enforcement confirmation , not UI-layer access control, server-side.
- Build Integrity Validation
-
Build integrity validation is the set of controls that verify the trustworthiness of the artifact production process , the chain of evidence from reviewed source code to deployed binary that demonstrates each step in the build was performed as expected, by authorized systems, with the intended inputs, and without unauthorized modification
build integrity is the control that addresses the gap that code signing leaves open , the gap between 'the artifact was signed with the vendor's key' and 'the artifact is an accurate representation of the reviewed source code.' For TPRM practitioners, this gap is where the most consequential supply chain attacks operate.
- Build Integrity Validation: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SLSA provenance attestations or transparency log references for recent releases; dependency lock file confirmation with digest verification policy; build environment isolation description , ephemeral environments or equivalent.
- Build Pipeline Integrity
-
Build pipeline integrity matters for TPRM because the software vendor whose pipeline is compromised produces compromised software , regardless of how strong their production security controls are.
build pipeline integrity matters for TPRM because the software vendor whose pipeline is compromised produces compromised software , regardless of how strong their production security controls are.
- Build Pipeline Integrity: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: CI/CD third-party integration inventory with credential scope; SLSA provenance generation and level; a vendor who confirms production environment security should be asked about build pipeline security. Production environment controls protect what is running. Build pipeline controls protect how it was built. The SolarWinds attack bypassed the first by compromising the second.
- Business associate agreement BAA
-
The contract HIPAA requires between a covered entity and anyone handling protected health information on its behalf, flowing down to subcontractors.
Signing it brings direct statutory obligations, including incident reporting on a deadline and returning or destroying data at the end, which a security certification does not cover.
Taught in PRV-203 · See also: Processor terms, Protected health information
- Business impact analysis
-
A business impact analysis works out, for each service or process, what happens over time if it is unavailable: which customers are affected, what revenue stops, what obligations are breached, and at what point the harm becomes unacceptable. Its outputs are the recovery objectives per service and a ranking of what to restore first when everything fails at once.
recovery objectives copied from a template protect nothing, and continuity plans that treat every service as equally urgent restore the wiki while payments are down. The BIA is the step that produces the numbers everything else in continuity depends on, and it is the step most often replaced by a spreadsheet of guesses.
C
- CAIQ
-
The Consensus Assessments Initiative Questionnaire is the Cloud Security Alliance's standard question set, mapped to its Cloud Controls Matrix. It is built for cloud service providers, and many publish a completed one in a public registry, which means a good share of your cloud vendors have already answered it before you ask.
it is the standard set most likely to exist already for a SaaS or infrastructure vendor, so it is the first thing to look for before writing a questionnaire of your own. It also comes up when a buyer asks you for one, at which point having a current completed CAIQ on your trust centre removes a category of request.
- Certification scope statements
-
A certification scope statement is the sentence on the certificate, or in the report's system description, that says what was actually examined: which products, which environments, which locations, which entities. Everything the certification claims applies within that sentence and nothing outside it. A buyer who reads certificates reads the scope statement before the logo.
a vendor's clean SOC 2 Type II covered its core platform. The buyer used a newer product from the same vendor, launched after the observation period and not named in the system description. The report was accurate, unqualified and irrelevant to the purchase, and nobody noticed because the check was that a report existed.
- Change management under CC8
-
CC8 requires that changes to infrastructure, data, software and procedures are authorised, designed, developed, tested, approved and implemented in a controlled way. It is the criterion that asks whether things reach production deliberately.
the normal change path is usually well controlled, because it is designed, documented and used every day. The emergency path is where it breaks. Something is down, a fix is needed now, the usual approval is skipped, and a week later nobody can find the record. Auditors know this and sample emergency changes deliberately.
- Charter Practitioner invitation
-
We invite you to join the Association as a Charter Practitioner.
- Children's data
-
GDPR sets the age at which a child can consent to information society services at sixteen, allowing member states to lower it to thirteen, and most have set it somewhere between. Processing a child's data on the basis of consent below that age requires parental authorisation. Codes such as the UK's Age Appropriate Design Code impose design obligations on services likely to be accessed by children, regardless of the intended audience.
services not aimed at children still attract them, and "not our audience" is not an assessment. The test is whether children are likely to access the service, and a general-purpose platform with no age gate is likely to be accessed by children. The obligations follow from that likelihood.
- CI/CD Access Reviews and Deprovisioning
-
CI/CD access reviews matter for TPRM because orphaned CI/CD accounts are access pathways into the pipeline environment that exist without active business justification. The former employee account is a credential that may have been compromised through phishing or credential theft without any active employee to notice suspicious activity.
CI/CD access reviews matter for TPRM because orphaned CI/CD accounts are access pathways into the pipeline environment that exist without active business justification.
- CI/CD Access Reviews and Deprovisioning: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: identity lifecycle integration for employee offboarding; service account and vendor account deprovisioning process; CI/CD access inventory with justification and owner.
- CI/CD Audit Logging and Observability
-
CI/CD audit logging matters for TPRM because the vendor's ability to investigate a supply chain compromise or security incident in their pipeline depends on the quality and retention of their CI/CD audit trail.
CI/CD audit logging matters for TPRM because the vendor's ability to investigate a supply chain compromise or security incident in their pipeline depends on the quality and retention of their CI/CD audit trail.
- CI/CD Audit Logging and Observability: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: CI/CD audit log retention period; immutable external storage for audit logs; event completeness , context captured with deployment events.
- CI/CD Credential Management Failures
-
CI/CD credential management matters for TPRM because it determines the worst-case blast radius of a pipeline compromise. The vendor whose pipeline uses a single service account with production deployment credentials has a blast radius of full production access from any pipeline compromise.
CI/CD credential management matters for TPRM because it determines the worst-case blast radius of a pipeline compromise.
- CI/CD Credential Management Failures: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: workload Identity implementation confirmation or roadmap; production credential isolation to deployment steps only; service account audit for credential scope.
- CI/CD Platform Security , GitHub Actions and GitLab CI Risk
-
Community Action: Approved at v2.1. Updated to v2.2: New Functionality.
CI/CD platform security matters for TPRM because the actions and components that run in vendor CI/CD pipelines are third-party code executing with pipeline credentials , the same threat model as application dependencies, applied to the build infrastructure rather than the application itself.
- CI/CD Platform Security , GitHub Actions and GitLab CI Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SHA pinning implementation in workflow files; approved action list or publisher restrictions; a vendor who confirms CI/CD security should be asked about action pinning and approval governance. Application dependency pinning controls which code runs in the application. Action pinning controls which code runs in the pipeline that builds the application.
- CI/CD Security for Regulated Industries
-
Regulated industry CI/CD security matters for TPRM because compliance certifications in regulated industries may not reflect CI/CD pipeline compliance if the certification scope did not include a rigorous assessment of the specific CI/CD requirements.
regulated industry CI/CD security matters for TPRM because compliance certifications in regulated industries may not reflect CI/CD pipeline compliance if the certification scope did not include a rigorous assessment of the specific CI/CD requirements.
- CI/CD Security for Regulated Industries: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: CI/CD pipeline to regulatory requirement mapping; gap assessment results and remediation status; compliance evidence for CI/CD-specific controls.
- Cloud Network Security Architecture
-
Cloud network security architecture matters for TPRM because cloud migration frequently transfers application workloads to cloud infrastructure without transferring the network security discipline that governed the on-premises environment.
cloud network security architecture matters for TPRM because cloud migration frequently transfers application workloads to cloud infrastructure without transferring the network security discipline that governed the on-premises environment.
- Cloud Network Security Architecture: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: security group 0.0.0.0/0 audit results; a vendor who confirms cloud security should be asked about security group configuration. Cloud security groups are the primary network security control in cloud environments. 0.0.0.0/0 on management ports exposes instances to the entire internet regardless of application-layer security controls.
- Cloud Security
-
Cloud security in the context of third-party risk is not primarily about the cloud provider's infrastructure , that part is largely handled. The real risk lives in how your organization has configured its cloud environment and how vendors are permitted to operate within it.
when a vendor operates inside your cloud environment, the traditional model of third-party risk , assess controls, receive attestation, file the report , breaks down almost completely.
- Cloud Security: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: a documented and defensible permission set for the vendor's cloud role , not a screenshot of AdministratorAccess; evidence of CSPM or equivalent tooling applied to environments they manage; a defined process for notifying customers of configuration changes made within their environment.
- Cloud Workload Isolation Failures
-
Cloud workload isolation is the set of technical mechanisms that prevent one workload , an application, a process, a container, a virtual machine , from accessing the memory, storage, network traffic, or execution context of another workload running on the same underlying infrastructure.
workload isolation is the technical guarantee that underpins multi-tenant vendor environments.
- Cloud Workload Isolation Failures: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: confirmation that privileged containers are prohibited or tightly controlled in production environments; a defined patching SLA for critical container runtime vulnerabilities , ideally 24-72 hours for critical CVEs; penetration testing scope documentation confirming workload isolation scenarios are included.
- Code Signing and Its Limits
-
Code signing limits matter for TPRM because enterprises that require code signing as a supply chain security control may have a false sense of assurance about the authenticity of signed software.
code signing limits matter for TPRM because enterprises that require code signing as a supply chain security control may have a false sense of assurance about the authenticity of signed software.
- Code Signing and Its Limits: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: HSM or equivalent key protection confirmation; a vendor who confirms code signing should be asked about key protection and transparency logging. Signature verification confirms the key signed the artifact. Key protection prevents compromise. Transparency logging detects compromise. All three are required for meaningful code signing assurance.
- Code Signing Practices
-
Code signing is frequently cited in vendor security assessments as evidence of artifact integrity and distribution security. For TPRM practitioners, the 3CX and SolarWinds attacks demonstrate that a signed artifact from a vendor's legitimate key can still be malicious if the build environment that produced it was compromised.
code signing is frequently cited in vendor security assessments as evidence of artifact integrity and distribution security.
- Code Signing Practices: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: signing key storage confirmation , HSM-based or equivalent tamper-resistant storage; automated signing pipeline access controls , signing key inaccessible to individual developer access; SLSA provenance attestations or equivalent build provenance documentation.
- Common control frameworks
-
A common control framework is a single set of controls describing what your organization actually does, with a stable identifier for each, mapped outward to every framework you are assessed against. Instead of a SOC 2 control set, an ISO control set and a HITRUST control set maintained by three teams, one set of thirty to eighty controls answers all three, and each piece of evidence is produced once.
the second framework is where programme cost doubles, and it should not. Most of what SOC 2, ISO 27001, NIST CSF and HITRUST require is the same underlying practice expressed differently: access granted deliberately and reviewed, changes approved, incidents handled, vendors assessed. The differences are in emphasis and evidence expectations, not in what you do on Monday.
- Compensating controls
-
A compensating control is an alternative measure adopted where a required control cannot be implemented as specified, for a genuine and documented constraint. It has to meet the intent of the original requirement and provide comparable rigour, and the reasoning has to be written down in a form an assessor can test. It is more work than compliance, not less.
every framework has requirements that some organizations cannot meet literally. A legacy system that cannot support multi-factor authentication, a vendor who cannot sign a particular clause, a process that a regulator's wording assumes and your business does not have. The compensating control is the legitimate route around each, and it is also the route most often abused as a way to skip something inconvenient.
- Complementary controls in contracts
-
CUECs describe what a customer must do for the vendor's controls to be effective. Increasingly, vendor contracts reference the CUECs directly, making the customer's implementation of them a contractual obligation rather than a recommendation in an appendix.
if a breach traces to a control the vendor's report listed as the customer's responsibility, the vendor will point to that list, and to the contract that incorporates it. The CUEC section has quietly become the document that decides who was at fault.
- Complementary subservice organisation controls
-
Complementary subservice organization controls, CSOCs, are the controls the audited company assumes its subservice organization performs. Physical security of the data centre. Isolation between tenants at the hypervisor. Secure disposal of hardware. They are stated in the report and tested by nobody in it.
CUECs push responsibility toward you, the customer. CSOCs push it toward the provider beneath the vendor. Together the two lists describe everything the report's opinion does not cover, and reading both is the only way to understand what the opinion is actually an opinion about.
- Complementary user entity control CUEC
-
A control the service organization assumes its customer operates, listed in the assurance report and relied on by the auditor's opinion.
It is an obligation that lands on you. A clean opinion means the service is secure if you do your part, and the report tells you what your part is.
Taught in TPR-215 · See also: Subservice organisation, Type I and Type II
- Complementary user entity controls (CUECs)
-
A vendor's controls only work if you do your part, and CUECs are your part, written out by the vendor. They are the controls the vendor assumes you operate for their environment to be secure: enforcing MFA on the users you create, reviewing the access you provisioned, setting the retention value, keeping your own API keys out of source control. They sit in a section of the SOC 2 report that most readers skip.
a SOC 2 report is evidence about the vendor. The CUEC list is the one part of it that is about you, and the auditor tested none of it, because the auditor was engaged by the vendor and has no view into your side. Every CUEC is a control the vendor has declined responsibility for, in writing, and handed back.
- Compliance Automation Gaps
-
Compliance automation platforms , Drata, Vanta, Secureframe, and similar tools , automate the collection of compliance evidence, the monitoring of control effectiveness, and the assessment of readiness for security certifications.
compliance automation gaps matter for TPRM because automated compliance monitoring is increasingly cited by vendors as evidence of continuous control effectiveness.
- Compliance Automation Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: compliance platform integration scope inventory; confirmation of recent additions' integration status; SOC 2 system description scope alignment confirmation.
- Compliance vs Security Gap
-
Compliance is the state of conformance with a defined set of requirements , a standard, a regulation, a framework , for a defined scope at a point in time. Security is the ongoing resistance to actual threats across the full attack surface.
compliance versus security matters for TPRM because compliance certifications are the most commonly used third-party evidence in vendor security assessments , and they systematically have the limitations described.
- Compliance vs Security Gap: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: out-of-scope adjacent system inventory with connectivity to in-scope environment; post-assessment change log with compliance impact assessment; scope gap identification and compensating assessment.
- Compliance-as-Code in CI/CD
-
Compliance-as-code matters for TPRM because point-in-time compliance certifications , PCI DSS QSA reports, SOC 2 auditor reports, ISO 27001 certifications , accurately describe compliance state at audit time but cannot confirm current compliance state if significant time has elapsed.
compliance-as-code matters for TPRM because point-in-time compliance certifications , PCI DSS QSA reports, SOC 2 auditor reports, ISO 27001 certifications , accurately describe compliance state at audit time but cannot confirm current compliance state if significant time has elapsed.
- Compliance-as-Code in CI/CD: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: compliance-as-code implementation and framework coverage; compliance drift detection and alerting; a vendor who confirms compliance certification should be asked about continuous monitoring since certification. Certification confirms compliance at audit time. Continuous compliance monitoring confirms compliance state has been maintained. Both are needed for current compliance assurance.
- Concentration risk
-
Exposure created when many of your services depend on the same provider, region, firm or rail.
Some concentration is rational; the obligation is to know about it and plan for it. Nine independent vendors on one cloud region fail together.
Taught in TPR-250 · See also: Fourth party
- Conditional Access , The Gap Between Policy and Enforcement
-
Conditional access gaps matter for TPRM because legacy authentication bypass undermines the MFA requirement that is the primary credential theft defence.
conditional access gaps matter for TPRM because legacy authentication bypass undermines the MFA requirement that is the primary credential theft defence.
- Conditional Access Gaps
-
Conditional access is a security policy model in which access decisions are made based on multiple contextual signals rather than solely on whether authentication succeeded.
conditional access gaps matter for TPRM because they determine whether the access controls that govern how vendor employees and their own internal users access sensitive data are genuinely risk-aware or superficially compliant.
- Conditional Access Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: device compliance requirement documentation , MDM enrollment required for sensitive access; conditional access signal inventory , all conditions evaluated in access policies; personal device access policy , explicitly prohibited for production access.
- Consent
-
Consent under GDPR must be freely given, specific, informed and unambiguous, indicated by a clear affirmative action, and as easy to withdraw as it was to give. The controller must be able to demonstrate that it was obtained. Consent bundled with terms of service, obtained through pre-ticked boxes, or made a condition of a service that does not need it, fails.
consent is the most demanding basis, and the one whose failure modes are most visible. A regulator can look at a signup form and see whether the box was pre-ticked. A single consent covering several distinct purposes fails the specificity requirement. A consent that cannot be withdrawn without calling a helpline fails the withdrawal requirement.
- Consent management platform CMP
-
The component that holds advertising and analytics tags until the visitor has chosen, then releases only the categories agreed.
The failures are almost never the banner wording. They are tags firing before the choice, which makes the banner theatre.
Taught in PRV-230 · See also: Global Privacy Control, Transparency and Consent Framework
- Consent records
-
A controller relying on consent must be able to demonstrate that the data subject consented. That means a record of who consented, when, to what specifically, by what mechanism, and what wording they were shown at the time. The record must survive changes to the wording, because consent obtained under one version does not cover purposes added in a later one.
the wording changes. Privacy notices are revised, purposes are added, a consent obtained in 2021 for marketing emails is later relied on for profiling that did not exist then. A record that captures only the fact of consent cannot show what it covered, and a regulator will treat it as covering nothing beyond what can be proven.
- Container Image Supply Chain
-
Container image supply chain risk matters for TPRM because container-delivered software includes the vendor's entire software stack , including system libraries and operating system components , not just the application code.
container image supply chain risk matters for TPRM because container-delivered software includes the vendor's entire software stack , including system libraries and operating system components , not just the application code.
- Container Image Supply Chain: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: full-layer container image scan results; base image rebuild cadence and process; container SBOM including system libraries.
- Container Registry Security in CI/CD
-
Container registry security matters for TPRM because the container images that enterprises deploy from vendor registries are the software supply chain delivery mechanism for containerised applications.
container registry security matters for TPRM because the container images that enterprises deploy from vendor registries are the software supply chain delivery mechanism for containerised applications.
- Container Registry Security in CI/CD: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: registry namespace authenticity , private or verified; a vendor who distributes container images should be asked about image signing and namespace verification. Image signing provides the authenticity assurance. Consumer pipeline signature verification enforces it. Both are required to close the typosquatting and distribution compromise vector.
- Container Security in CI/CD
-
Container security in CI/CD matters for TPRM because container-delivered software includes the entire software stack , base image, dependencies, and application , and vulnerability management must extend to all layers.
container security in CI/CD matters for TPRM because container-delivered software includes the entire software stack , base image, dependencies, and application , and vulnerability management must extend to all layers.
- Container Security in CI/CD: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: container scanning tool and full-layer coverage confirmation; a vendor who confirms container scanning should be asked about layer coverage. Application layer scanning covers vendor-added dependencies. Full-layer scanning covers the execution environment. Both are required for complete container vulnerability management.
- Continuous Compliance Reality
-
Continuous compliance is a programme design philosophy that replaces periodic point-in-time compliance assessments with automated, ongoing checks that monitor control effectiveness between formal assessment cycles. The term continuous implies constant monitoring , a programme that would immediately detect any control failure.
continuous compliance reality matters for TPRM because the term continuous compliance in vendor security descriptions creates an impression of real-time monitoring that the operational implementation does not always support.
- Continuous Compliance Reality: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: check frequency for critical controls; alert routing configuration , incident vs compliance queue; target and actual response time for critical compliance failures.
- Continuous Monitoring Gaps
-
Continuous monitoring in TPRM is the ongoing collection and evaluation of signals about vendor security posture between formal assessment cycles , using external security rating data, threat intelligence feeds, public vulnerability disclosures, corporate intelligence, and regulatory action monitoring to detect material changes in vendor r
continuous monitoring gaps matter for TPRM because regulatory examiners in financial services, healthcare, and critical infrastructure are increasingly expecting continuous monitoring as a component of third-party risk programmes , not as a replacement for periodic assessments but as a supplement that detects material changes between form
- Continuous Monitoring Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: material change notification process documentation; key security leadership change notification policy; security incident notification below formal contractual threshold.
- Continuous monitoring platforms
-
Compliance automation platforms connect to your cloud, identity, ticketing and code systems, check configurations continuously against control requirements, and gather evidence automatically as controls run. They surface gaps between audits and remove much of the manual work of evidence collection.
they genuinely reduce the cost of a SOC 2, and they make control drift visible within days rather than at the next audit. For a small team they can be the difference between an audit that is manageable and one that is not.
- Continuous Monitoring vs Point-in-Time Assessment
-
Continuous monitoring matters because the risk events that most warrant TPRM response , vendor breaches, infrastructure changes, leadership turnover , typically occur between assessments rather than at the convenient time of the annual review cycle.
continuous monitoring matters because the risk events that most warrant TPRM response , vendor breaches, infrastructure changes, leadership turnover , typically occur between assessments rather than at the convenient time of the annual review cycle.
- Continuous Monitoring vs Point-in-Time Assessment: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: contractual self-reporting obligation with specific triggers; notification timeline for different change types; recent examples of proactive notification to customers.
- Continuous vendor monitoring
-
Continuous monitoring means deciding which events change a vendor's risk, watching for those events, and letting each one trigger a defined action with an owner and a clock. It is not a product. Four things are worth watching: breach intelligence about your suppliers, expiry of the artefacts you rely on, changes at the vendor such as new subprocessors or new ownership, and changes in your own usage of them.
vendors change and the changes are not annual. A supplier is breached in March, their report lapses in June, they add a subprocessor in August and are acquired in October. None of that appears in a rating recorded in January, and the rating is what the register shows. The fourth trigger, your own usage expanding, is the one programmes miss most, because it happens on your side and nothing arrives to announce it.
- Contract Security Requirements Enforcement
-
Contract security requirements enforcement matters because the risk reduction value of contractual security requirements depends entirely on whether they are implemented.
contract security requirements enforcement matters because the risk reduction value of contractual security requirements depends entirely on whether they are implemented.
- Contract Security Requirements Enforcement: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: requirement-specific compliance confirmation with evidence; technical evidence for encryption and access control requirements; incident notification process documentation showing 72-hour compliance.
- Contractual vs Actual Controls
-
Contractual security requirements define the security posture that a vendor must maintain as a condition of the business relationship. They establish obligations, define standards, and create legal recourse if standards are not met.
contractual versus actual controls matters for TPRM because regulatory frameworks increasingly expect that organizations not only have security requirements in vendor contracts but can demonstrate that those requirements are being met.
- Contractual vs Actual Controls: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: technical configuration evidence for specific contractual requirements; exception disclosure , known gaps from contractual requirements; legacy pathway assessment against contractual requirements.
- Control Duplication
-
Control duplication is the maintenance of multiple instances of the same security control function across an organization , separate tools, separate processes, or separate programmes performing equivalent security functions with overlapping or identical scope.
control duplication matters for TPRM because vendors who maintain duplicate controls may have a compliance posture that appears comprehensive , multiple tools, multiple programmes, defence in depth , while the actual coverage is less complete than it appears and the operational overhead is significantly higher than a rationalised programm
- Control Duplication: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: duplication identification and rationalisation records.
- Control Inheritance Misunderstandings
-
Control inheritance is the practice of relying on a third-party certification, audit, or assessment as evidence that certain controls are in place, rather than conducting direct assessment of those controls.
control inheritance misunderstandings matter for TPRM because they create a specific type of false assurance , the confidence that comes from a genuine, well-regarded certification that does not actually cover the assets relevant to the customer's risk.
- Control Inheritance Misunderstandings: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: certification scope statement or system description confirming coverage of relevant service; list of explicitly excluded systems from SOC 2 system description; statement of Applicability for ISO 27001 if requested.
- Control Mapping Inconsistencies
-
Control mapping is the practice of documenting the relationships between implemented security controls and the requirements of multiple compliance frameworks, regulatory standards, and customer requirements.
control mapping inconsistencies matter for TPRM because mapping documents are frequently provided as compliance evidence in vendor assessments , showing that the vendor's controls satisfy the requirements relevant to the customer.
- Control Mapping Inconsistencies: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: control content description specifically addressing the requirement's text; training curriculum or procedure documentation showing requirement-specific content; gap identification if requirement is partially rather than fully satisfied.
- Control objective and control activity
-
A control objective is the outcome you need. A control activity is what somebody actually does to achieve it. "Access to production systems is appropriate" is an objective. "Managers review a system-generated list of their team's production access each quarter and record approval or removal for each entry" is an activity. Auditors test activities.
control matrices frequently list objectives and call them controls. When the auditor asks for evidence, there is nothing to produce, because an objective does not leave a trace. It can only be discussed. The engagement stalls while the activity is worked out retrospectively.
- Control owner
-
The named person accountable for a control operating and for the evidence it produces.
A control without an owner is one nobody notices failing. Ownership is what turns a control description into something testable.
Taught in AUD-201 · See also: Evidence, Risk acceptance
- Control owner and evidence owner
-
The control owner is the person accountable for the control operating as designed. The evidence owner is the person responsible for producing the artefact that proves it did. They are often different people, and the control can operate perfectly while the evidence is never captured, because nobody was responsible for capturing it.
audits fail on the handoff between the two. The manager who reviews access does the review; the analyst who was supposed to export the record is on leave; the auditor asks for the evidence; there is none. The control worked and the audit records an exception.
- Control Testing Depth
-
Control testing depth is the degree to which security testing exercises the controls, systems, and attack paths that are most relevant to the actual threat model , rather than the controls, systems, and attack paths that are easiest to test within a defined budget and timeline.
control testing depth matters for TPRM because penetration test reports are among the most commonly requested and most heavily weighted evidence items in vendor security assessments.
- Control Testing Depth: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: penetration test scope documentation including in-scope and out-of-scope systems; confirmation that authenticated API environments are in scope; testing methodology description , automated and manual components.
- Control testing versus control design
-
A control can fail in two distinct ways. A design failure means the control, even performed perfectly, would not achieve its objective: the review happens but the population it reviews is incomplete, or the approval step exists but sits after deployment. An operating failure means the control is well designed and did not run as designed: the review was skipped in month two, the approval was given after the fact.
auditors report the two separately, and the remediation is entirely different. A design failure needs the control redesigned. An operating failure needs the people and the cadence fixed. Treating one as the other wastes the remediation: retraining reviewers does not fix a population that missed the service accounts, and redesigning the review does not fix a reviewer who was on leave with nobody covering.
- Control vs Implementation Gap
-
The control versus implementation gap is the difference between what a security control is designed to do , as specified in policy, programme documentation, and procedure , and what it actually does in practice , as reflected in execution records, findings data, and operational metrics.
control implementation gaps matter for TPRM because the risk reduction provided by a security control depends entirely on the control's operational state , not its policy state.
- Control vs Implementation Gap: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: most recent penetration test date and current open finding count with oldest finding age; remediation SLA performance rate , percentage compliant, not SLA policy; most recent security committee meeting date.
- Coordinated Response Failures
-
Coordinated response failures are the breakdowns in joint incident response that occur when vendor and customer IR plans contain conflicting objectives, incompatible procedures, or incompatible timelines that cannot be reconciled without negotiation during an active incident. Individual plans may be excellent in design and execution.
coordinated response failures matter for TPRM because the customer's outcome in a shared incident depends on the quality of the coordinated response , and a coordinated response with plan conflicts resolved in real time during an active incident is a significantly worse outcome than a coordinated response with conflicts identified and res
- Coordinated Response Failures: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: acknowledged conflict with customer restoration SLA; pre-negotiated resolution for the conflict; joint tabletop including conflict scenario.
- COSO mapping
-
The Trust Services Criteria are built on the COSO Internal Control Integrated Framework, specifically its seventeen principles, extended with supplemental criteria for the trust services context. The Common Criteria CC1 through CC5 correspond directly to COSO's five components: control environment, risk assessment, control activities, information and communication, and monitoring.
it explains the presence of criteria about board oversight, organizational structure, competence and accountability in what most people expect to be a security report. Those come from COSO, and they are there because a control environment without governance behind it does not hold.
- Criteria versus controls in questionnaires
-
A security questionnaire asks about specific controls: do you encrypt at rest, do you rotate keys quarterly, do you review access monthly. A SOC 2 reports against criteria, with controls chosen by the vendor to meet them. The two rarely line up item to item, because the questionnaire assumes one way of meeting a criterion and the vendor may have chosen another.
a vendor can answer no to a specific control question and still meet the underlying criterion by a different route. Recording that as a gap, and pressing the vendor to adopt your preferred control, is asking them to change something that already works.
- Critical Vendor Exit Strategy Planning
-
Exit strategy planning matters because the inability to exit a critical vendor relationship without operational catastrophe is itself a risk , concentration risk, leverage risk, and operational resilience risk that the enterprise carries regardless of the vendor's security posture.
exit strategy planning matters because the inability to exit a critical vendor relationship without operational catastrophe is itself a risk , concentration risk, leverage risk, and operational resilience risk that the enterprise carries regardless of the vendor's security posture.
- Critical Vendor Exit Strategy Planning: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: transition assistance commitment with timeline; data portability and export format documentation; API documentation availability for exit integration.
- Cross-Border Data Flow Risks
-
Cross-border data flow risk arises when personal data moves between jurisdictions that have different data protection standards, creating regulatory compliance obligations that must be fulfilled for each transfer.
cross-border data flow governance matters for TPRM because the regulatory obligations that apply to international data transfers , SCCs, binding corporate rules, adequacy decisions , are the responsibility of the data exporter, not the data importer.
- Cross-Border Data Flow Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: geographic processing footprint map , all locations where customer data is processed; transfer mechanism inventory , mechanism type and current version for each transfer location; sub-processor transfer mechanism confirmation , not just list but mechanism coverage.
- Cross-border transfers
-
Chapter V of GDPR restricts the transfer of personal data outside the European Economic Area unless a transfer mechanism applies: an adequacy decision, standard contractual clauses, binding corporate rules, or one of the narrow derogations. The restriction attaches to the data wherever it goes, including onward transfers by the recipient.
access is a transfer. A support engineer in a third country viewing a European customer's record has transferred that data, even though it never left the European server. Remote administration, follow-the-sun support and offshore development are all transfers, and mapping only where data is stored misses most of them.
- Cross-Org Response Timelines
-
Cross-organization response timeline problems arise when security incidents affecting multiple organizations , particularly supply chain incidents targeting vendors and their customers in the same campaign , are investigated independently by each affected organization rather than through coordinated information sharing.
cross-org response timelines matter for TPRM because supply chain incidents frequently create co-targeting scenarios where coordinated response would produce faster detection and shorter attacker dwell time for all parties.
- Cross-Org Response Timelines: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: customer notification process for co-targeting scenarios; IOC sharing mechanism , STIX/TAXII, MISP, or bilateral agreement; ISAC participation in shared sector.
- Cross-Platform Visibility
-
Cross-platform visibility gaps are the security monitoring blind spots that exist at the interfaces between different technology platforms, managed services, and third-party operators , specifically the systems and environments where the monitoring responsibility boundary between two parties is ambiguous, assumed rather than confirmed, or
cross-platform visibility matters for TPRM because complex vendor technology environments , with multiple managed services, third-party operators, and hybrid infrastructure , create monitoring gap opportunities at every interface between parties.
- Cross-Platform Visibility: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: kubernetes runtime security monitoring confirmation; managed service security monitoring scope in agreement; a vendor who confirms endpoint, cloud, and network coverage should be asked about container and Kubernetes security monitoring specifically. The confirmed categories cover the confirmed components. The Kubernetes cluster hosting customer data requires its own confirmation.
- Cross-System Identity Propagation
-
Cross-system identity propagation is the process by which identity lifecycle events , user creation, role changes, and deprovisioning , are communicated from a central identity source (typically an IdP or IGA platform) to all connected systems, ensuring that identity state is consistent across the entire application landscape.
cross-system identity propagation matters for TPRM because vendors who access customer environments across multiple systems , project workspaces, client collaboration tools, shared development environments , may have IGA deprovisioning gaps for the customer-environment-adjacent systems that were deployed specifically for the engagement.
- Cross-System Identity Propagation: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: IGA connector list with last reconciliation date; shadow application discovery capability or process; post-departure access verification process covering non-IGA systems.
- Cross-Tenant Access Risks
-
Cross-tenant access risk is the possibility that one customer's data, workload, or environment within a multi-tenant cloud platform can be accessed, affected, or compromised as a result of another customer's presence on the same platform , or as a result of weaknesses in the platform's shared components that serve all tenants simultaneous
cross-tenant risk is one of the most underassessed dimensions of third-party cloud risk precisely because it is invisible in the standard assessment model.
- Cross-Tenant Access Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: a clear architectural description of tenant isolation , not a marketing statement, a technical explanation; documentation of support access controls including authorization requirements and audit logging; penetration testing reports or executive summaries confirming cross-tenant scenarios were tested.
- Cross-Tenant Attack Detection
-
Cross-tenant attack detection is the challenge of identifying when a security compromise affecting one customer's environment in a multi-tenant platform has accessed, or has the potential to access, other customers' environments through shared infrastructure components.
cross-tenant attack detection matters for TPRM because customers on multi-tenant platforms face a breach risk that originates in another customer's environment , a risk that is entirely outside their control and that depends on the vendor's ability to detect cross-tenant access and notify affected customers.
- Cross-Tenant Attack Detection: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: cross-tenant investigation checklist , which layers are verified; co-tenant notification trigger and timeline; shared database access control review procedure.
- Crosswalks
-
A crosswalk is a mapping between the requirements of two or more frameworks, showing which requirement in one corresponds to which in another. Good ones are graded, marking whether a correspondence is full, partial or merely thematic. Poor ones are lists of numbers side by side, produced once by someone who read the headings.
a crosswalk is how a control programme avoids doing the same work three times, and it is also how it quietly overclaims. A partial mapping recorded as full is where a programme starts telling assessors that a requirement is met when only most of it is. Published crosswalks from framework bodies and vendors range from careful to decorative, and the reader usually cannot tell which from the format.
D
- Dark patterns in consent
-
Dark patterns are interface designs that steer users toward a choice they would not otherwise make: an accept button in bold colour beside a reject link in grey, a rejection path buried three clicks deep, repeated prompting after refusal, confusing double negatives, or a cookie wall that blocks content until consent is given. Regulators now name specific patterns in guidance and enforcement.
consent obtained through a dark pattern is not freely given, and consent that is not freely given is not consent. The processing that relies on it has no lawful basis. European regulators have fined companies specifically for asymmetric consent interfaces, and the design itself is now evidence.
- DAST Coverage Gaps in Vendor Apps
-
DAST is positioned in most vendor security programs as the complement to SAST , where static analysis finds code-level vulnerabilities before deployment, dynamic testing finds runtime vulnerabilities in the deployed application.
DAST is positioned in most vendor security programs as the complement to SAST , where static analysis finds code-level vulnerabilities before deployment, dynamic testing finds runtime vulnerabilities in the deployed application.
- DAST Coverage Gaps in Vendor Apps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: coverage percentage for the most recent DAST scan with explicit statement of what is excluded from scope; confirmation of authenticated testing with description of how authentication is managed in the scanner; environment confirmation , production or production-equivalent , with description of any material differences from production.
- DAST in the CI/CD Pipeline
-
DAST effectiveness matters for TPRM because the authentication and configuration settings under which DAST is run determine what vulnerabilities it can find.
DAST effectiveness matters for TPRM because the authentication and configuration settings under which DAST is run determine what vulnerabilities it can find.
- DAST in the CI/CD Pipeline: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: DAST target environment configuration description; DAST scope documentation , endpoints and authentication flows covered; a vendor who confirms DAST scanning should be asked about the configuration of the environment being tested. DAST tests what is running. If what is running doesn't match production configuration, DAST findings don't describe production vulnerabilities.
- Data Access Logging Gaps
-
Data access logging is the systematic capture of records showing which user or process accessed which data, when, from what location, and what operation was performed , read, write, export, delete, query.
data access logging matters for TPRM because the insider threat , a vendor employee abusing their legitimate access to customer data , is one of the most consequential and least detectable threat categories in the third-party risk landscape.
- Data Access Logging Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: insider threat detection capability description , specific control that would detect bulk export activity; application-layer access logging confirmation with bulk export alerting; log retention period and calibration basis.
- Data Access Privilege Creep
-
Privilege creep is the gradual accumulation of access rights over time as individuals receive new access for specific purposes without losing previous access when those purposes conclude. Each individual grant follows the correct provisioning process , request, approval, access.
privilege creep matters for TPRM because it creates insider threat risk that is invisible to assessments focused on individual access grants.
- Data Access Privilege Creep: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: cumulative profile review evidence for long-tenure population; role-change access retirement trigger confirmation; IGA lifecycle management platform if applicable.
- Data Access via APIs
-
APIs have become the primary interface through which data moves between systems , the mechanism through which vendor integrations, mobile applications, partner connections, and internal services access the data that databases and application systems hold.
API data access matters for TPRM because APIs are the actual data access mechanism for virtually all vendor integrations , and API-layer security controls determine the actual data protection that integrations receive regardless of the database-level controls that governance assessments typically evaluate.
- Data Access via APIs: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: field filtering capability confirmation , per-integration field scope or full-record return; rate limiting configuration , per-key limits on data retrieval endpoints; API security test scope confirmation including field authorization and enumeration testing.
- Data Anonymization Myths
-
Data anonymization is the process of transforming personal data in a way that irreversibly prevents the identification of the individuals to whom it relates , removing or altering identifying information such that re-identification is not reasonably possible using means likely to be available to a potential adversary.
data anonymization matters for TPRM because it is frequently used as a mechanism to reduce the governance burden on data shared with analytics, research, and AI/ML vendors , the argument being that anonymized data is not personal data and therefore does not require the same access controls, DPA provisions, and security requirements as ide
- Data Anonymization Myths: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: anonymization technique documentation , specific method applied, not just 'identifiers removed'; re-identification risk assessment using formal tools and realistic auxiliary data assumptions; periodic reassessment confirmation for data anonymized more than 12 months ago.
- Data Auditability Challenges
-
Data auditability is the capability to produce evidence of compliance with data protection obligations on demand , not through a compliance program that generates evidence when a regulator asks, but through an ongoing evidencing infrastructure that captures compliance events continuously and retains them in a format that supports audit re
data auditability matters for TPRM because it is the capability that converts compliance practice into defensible compliance , the ability to demonstrate to a regulator, a customer, or an auditor that data protection obligations are being met, when they are met, and that the evidence of meeting them is available for review.
- Data Auditability Challenges: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: access review output in searchable, audit-ready format; deletion log with system, schedule, and confirmation documentation; DSAR log with fulfillment status and timeline evidence.
- Data Breach Notification Gaps
-
Data breach notification governance in vendor relationships is the set of contractual and operational mechanisms that ensure a vendor communicates security incidents affecting customer data to the customer in a timeframe that enables the customer to fulfill their own regulatory notification obligations.
breach notification gaps matter for TPRM because the customer's regulatory obligations are not suspended while the vendor investigates.
- Data Breach Notification Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: incident response process documentation showing customer notification as a defined, time-bound step; notification timeline specification , maximum hours between discovery and notification; initial notification template with minimum content confirmation.
- Data classification
-
Data classification assigns handling requirements to information by sensitivity. A typical scheme has four tiers: public, internal, confidential and restricted, with each tier carrying rules for storage, transmission, access, sharing and disposal. Personal data and special category data are usually mapped into the higher tiers.
controls, retention and access decisions all reference the classification, so an estate with no classification forces one policy for everything, which is either too strict for the public material or too loose for the restricted. Classification is what allows proportionate handling.
- Data Deletion Validation
-
Data deletion validation is the process of confirming that data has been completely and irreversibly removed from all locations where it existed , not just confirming that a deletion action was performed on the systems that were in scope for the deletion request.
data deletion validation matters for TPRM because the right to erasure under GDPR and equivalent rights under CCPA, LGPD, and other frameworks create legally enforceable obligations that require complete deletion , from all systems, including backups and archives , not just deletion from primary active systems.
- Data Deletion Validation: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: system coverage confirmation , list of systems searched and deletion confirmed in each; deletion log records where available , action evidence rather than absence evidence; backup and archive deletion confirmation explicitly addressed.
- Data Exfil Detection Gaps
-
Data exfiltration detection gaps are the limitations in a security programme's ability to identify when data is being transferred outside the organization by an attacker , gaps that arise from threshold calibration, detection architecture, and the specific exfiltration techniques that attackers use to circumvent configured detection.
data exfiltration detection gaps matter for TPRM because DLP is the primary evidence in post-breach investigations about whether data was actually exfiltrated and in what volume , and a DLP system that evaluated twelve transfers individually without detecting session-level exfiltration provides no evidence of a breach that an investigator
- Data Exfil Detection Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: DLP session aggregation configuration confirmation; a vendor who confirms DLP deployment with configured thresholds should be asked whether the configuration includes session aggregation. Per-event thresholds detect single-event exfiltration. Session aggregation detects fragmented exfiltration. Both require specific configuration. Both require specific confirmation.
- Data Exfiltration Paths
-
Data exfiltration is the unauthorized transfer of data from a controlled environment to an uncontrolled one , whether through malicious intent, employee negligence, or convenience-driven shortcuts that bypass security controls.
data exfiltration path governance matters for TPRM because the exfiltration risk that a vendor presents is determined not by the strength of the controls they have implemented on the channels they have addressed but by the completeness of the controls across all channels data can travel.
- Data Exfiltration Paths: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: personal email forwarding DLP coverage confirmation , technical control or explicit gap acknowledgment; personal device and account policy documentation , explicit prohibition and enforcement mechanism; exfiltration incident history , recent incidents, channel involved, and control outcome.
- Data Governance Tooling Gaps
-
Data governance tooling is the technical infrastructure that operationalizes governance policies , the platforms, tools, and automated systems that execute classification, enforce retention, manage access reviews, maintain data inventories, and monitor compliance continuously rather than depending on periodic manual processes.
data governance tooling gaps matter for TPRM because they determine the actual consistency and scale of governance program execution , the gap between what the policy describes and what manual processes can deliver.
- Data Governance Tooling Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: classification tooling name and coverage percentage; IGA platform name with auto-revocation confirmation; lifecycle management tooling with automated deletion log.
- Data Governance vs Enforcement
-
Data governance is the framework of policies, standards, and processes that define how data should be collected, classified, protected, retained, and disposed of within an organization.
data governance vs enforcement matters for TPRM because the assurance value of vendor data governance documentation depends entirely on whether that documentation reflects operational reality.
- Data Governance vs Enforcement: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: classification tooling deployment evidence , not the policy, the deployed system; retention automation configuration , not the policy schedule, the configured deletion process; internal audit findings and remediation status , evidence of governance compliance testing.
- Data Inventory Completeness
-
A data inventory is a documented record of all systems, databases, storage locations, and data flows that contain or process sensitive data within an organization's or vendor's environment.
data inventory completeness matters for TPRM because all downstream data governance controls , access management, encryption, retention policies, incident response scope , depend on the inventory identifying the systems to which those controls must be applied.
- Data Inventory Completeness: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: discovery scan evidence compared against documented inventory , with discrepancy documentation; inventory update process documentation , triggers and cadence; inventory scope confirmation , all relevant system categories included.
- Data Lifecycle Mismanagement
-
Data lifecycle management is the governance of data from creation or collection through use, retention, archiving, and eventual deletion or destruction.
data lifecycle mismanagement matters for TPRM because unauthorized data retention , holding data beyond the period authorized by the processing purpose , creates pure residual risk with no corresponding business value.
- Data Lifecycle Mismanagement: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: deletion process documentation , formal workflow from request to execution to verification; named lifecycle ownership , specific role responsible for execution and evidence provision; deletion verification evidence from a recent customer offboarding , demonstrating the process works.
- Data Lineage Across Third Parties
-
Data lineage is the traceable record of where data originated, how it has been transformed, and where it has traveled , a chain of custody that identifies every system, process, and party that has touched data from creation through current state.
data lineage across third parties matters for TPRM because the regulatory obligations that apply to customer data , processing limitations, geographic restrictions, sub-processor authorization requirements, data subject rights , apply to the data regardless of how many hops away from the customer it is.
- Data Lineage Across Third Parties: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: current sub-processor list with names, jurisdictions, data received, and processing purpose; change notification process documentation with customer opt-out rights; data repurposing prohibition confirmation , sub-processors contractually prohibited from using customer data for unauthorized purposes.
- Data map data inventory
-
A record of what data is held, where it lives, whose it is and where copies go, including logs, analytics, backups and non-production environments.
It is the input to rights operations, retention, breach scoping and vendor exposure. Doing it once avoids four separate discovery exercises.
Taught in DGV-220 · See also: Record of processing activities, Retention schedule
- Data mapping
-
Data mapping is the exercise of identifying what personal data an organization holds, where it lives, how it moves between systems and parties, who can access it, and what happens to it over its lifecycle. It is the empirical basis for the record of processing, the retention schedule, the transfer register and every rights request.
every other privacy obligation depends on it. An organization cannot honour an erasure request without knowing where the data is. It cannot assess transfers without knowing where the data goes. It cannot set retention without knowing what it holds. A programme without a map is a programme guessing.
- Data minimisation
-
Data minimisation requires that personal data be adequate, relevant and limited to what is necessary for the purposes for which it is processed. Collect what the purpose requires and no more. Keep it only as long as the purpose requires. It is one of the seven principles in GDPR Article 5 and among the hardest to enforce against a product team.
more data always looks useful later. A form that asks for date of birth when only age bracket is needed, a log that captures full request bodies when only status codes are required, a CRM that stores every field the integration offers. Each is a minimisation failure, and each expands the surface of every breach, every access request and every retention obligation.
- Data Minimization Failures
-
Data minimization matters for TPRM for a reason that is both legally significant and practically intuitive: you cannot breach data you do not have. Every data element transferred to a vendor beyond what is necessary for the stated purpose represents an unnecessary expansion of the breach surface.
data minimization matters for TPRM for a reason that is both legally significant and practically intuitive: you cannot breach data you do not have.
- Data Minimization Failures: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: specific data field inventory with purpose justification for each field received; confirmation that no fields are received without an active operational purpose; anonymization or pseudonymization capability assessment for fields where identification is not operationally required.
- Data Ownership Ambiguity
-
Data ownership in vendor relationships encompasses two distinct but frequently conflated categories. The first is ownership of the data itself , the customer records, transaction logs, behavioral data, and operational information that the customer shares with the vendor for processing.
data ownership ambiguity matters for TPRM because the commercial and competitive consequences of ownership gaps can be as significant as security breaches.
- Data Ownership Ambiguity: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: derived asset ownership provision , explicit contract language on model and algorithm ownership; competitive use restriction confirmation , prohibition on offering competitor capabilities derived from customer engagement; post-termination asset handling documentation , deletion or return of trained models at contract end.
- Data portability
-
The right to data portability allows a person to receive the personal data they provided to a controller in a structured, commonly used, machine-readable format, and to transmit it to another controller. It applies only where the processing rests on consent or contract, and only where it is carried out by automated means.
it is frequently requested for data it does not cover. Inferences you drew, scores you calculated, and records you created about the person from other sources are not data they provided, and are not portable. Data processed under legitimate interests or legal obligation is not in scope either.
- Data processing agreements
-
A data processing agreement is the contract GDPR Article 28 requires between a controller and a processor. Its mandatory content is listed in the article: the subject matter and duration, the nature and purpose, the types of data and categories of data subjects, and the obligations of both parties, including processing only on instruction, confidentiality, security, sub-processor rules, assistance with rights and DPIAs, deletion or return at the end, and audit rights.
a DPA missing any of the mandatory terms is not compliant, however professionally drafted. Sub-processor consent and audit rights are the two most often absent from vendor templates, and their absence is usually not deliberate. The template was written for a different purpose and never checked against the article.
- Data protection impact assessment DPIA, PIA
-
An assessment required where processing is likely to result in a high risk to people, covering necessity, proportionality, risks and mitigations.
Its practical purpose is to change the design while changing it is still cheap. Completed after the design is fixed, it can only document.
Taught in PRV-250 · See also: Record of processing activities, Legitimate interests
- Data protection impact assessments
-
A data protection impact assessment is a documented process for identifying and minimising the data protection risks of a project before it begins. It is mandatory where processing is likely to result in high risk to individuals, particularly with new technologies, large-scale monitoring, systematic evaluation or profiling, or special category data at scale.
the DPIA is the documented moment when someone asked whether this should be built the way it is being built, and what could be done differently. It is also what a regulator asks for first after a complaint, and its absence where one was required is a breach in itself, independent of whether the processing turned out to be harmful.
- Data protection officers
-
GDPR requires a data protection officer in three circumstances: the organization is a public authority, its core activities involve large-scale regular and systematic monitoring of individuals, or its core activities involve large-scale processing of special category or criminal conviction data. Headcount and revenue are not the test.
many organizations appoint a DPO voluntarily, and doing so brings the full statutory obligations with it: independence, adequate resources, direct reporting to the highest management level, protection from dismissal for performing the role, and involvement in all data protection matters. A voluntary DPO is not a lighter version.
- Data Replication Risks
-
Data replication is the creation of copies of data for operational, availability, and analytical purposes , hot standbys that ensure continuity if the primary system fails, backup copies that enable recovery from data loss events, DR environments that mirror production for failover testing, development and testing environments populated w
data replication risk matters for TPRM because the vendor's security assessment typically covers the primary system , the database that the vendor describes in their security documentation, that their SOC 2 assessment covers, and that their access review process maintains.
- Data Replication Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: replica inventory , all systems holding customer data with ownership and access control status; development environment data confirmation , synthetic/masked data or production data with equivalent controls; deletion scope confirmation , all replicas included in deletion processes.
- Data residency and sovereignty
-
Data residency is where data is physically stored. Data sovereignty is whose laws can compel access to it. A dataset stored in a Frankfurt region operated by a company headquartered in the United States is resident in Germany and subject to US legal process, because the operator can be compelled under US law regardless of where the servers sit.
customers ask about sovereignty and are answered about residency. A region selector in a cloud console satisfies residency in one click and says nothing about sovereignty, because the operator's legal exposure follows the operator, not the data centre.
- Data Residency vs Access
-
Data residency is a constraint on where data is physically stored , which data center, which country, which jurisdiction. It is a meaningful control in the context of data sovereignty requirements, regulatory jurisdiction rules, and cross-border transfer restrictions that specify where personal data may rest at storage.
data residency commitments are increasingly used as a primary GDPR compliance mechanism , the argument being that data stored in the EU never undergoes a restricted international transfer under Chapter V of GDPR.
- Data Residency vs Access: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: access geography map , all locations from which designated-region data is accessed, with authorization framework for each; backup replication geography confirmation , within designated region or with approved transfer mechanisms; access geography log availability confirmation.
- Data Segregation Failures
-
Data segregation in multi-tenant environments is the architectural and technical approach used to ensure that one customer's data cannot be accessed through another customer's authenticated session.
data segregation failures matter for TPRM because they represent a risk category that is specific to multi-tenant platforms and that can expose customer data to other customers without any attacker involvement , through bugs, configuration errors, and design flaws that are intrinsic to the multi-tenant architecture.
- Data Segregation Failures: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: multi-tenant architecture description , specific isolation mechanism; cross-tenant penetration test scope confirmation , isolation bypass as explicit objective; database-level row security confirmation or alternative architectural isolation.
- Data sharing agreements
-
Where two controllers share personal data, each for their own purposes, the arrangement is controller to controller and needs a data sharing agreement rather than an Article 28 DPA. The agreement covers the purpose of the sharing, the lawful basis each party relies on, the data shared, security measures, how rights requests are handled, what each party tells the data subjects, and what happens on termination.
Article 28 DPAs govern processor relationships and do not fit controller-to-controller sharing at all. A DPA instructs the processor to act only on the controller's instructions, which is meaningless between two controllers each deciding their own purposes. Signing one for a sharing arrangement documents both parties in roles neither holds.
- Data Sovereignty Enforcement
-
Data sovereignty is the principle that data is subject to the laws and regulations of the jurisdiction in which it is stored or processed, and that the organization controlling that data is protected from foreign government access except through defined legal mechanisms , mutual legal assistance treaties, formal court orders with appropri
data sovereignty enforcement matters for TPRM because public sector customers, regulated industries, and organizations with national security data handling obligations increasingly require genuine data sovereignty , not storage location sovereignty that can be bypassed through corporate structure and extraterritorial law.
- Data Sovereignty Enforcement: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: corporate structure disclosure , ultimate parent and jurisdiction; extraterritorial law exposure assessment for parent jurisdiction; operational access segregation confirmation , parent company infrastructure access.
- Data subject access requests
-
A data subject access request is a person exercising their right to obtain the personal data an organization holds about them, along with the purposes, recipients, retention period and source. The controller has one month to respond, extendable by two further months for complex or numerous requests, and the clock runs from receipt.
requests arrive anywhere. A support ticket, a reply to a marketing email, a message on social media, a comment in a complaint. There is no required form, and the deadline runs from the moment the organization received it, not from the moment someone recognised it as a DSAR and forwarded it to the right team.
- Data subject rights beyond access
-
Beyond access and erasure, GDPR gives individuals the right to rectification of inaccurate data, restriction of processing in specific circumstances, objection to processing based on legitimate interests or for direct marketing, and rights relating to automated decision-making. Each carries the same one-month response deadline and the same obligation to respond.
processes are built for access requests, because those are the most common, and improvised for everything else. An objection is handled as a deletion. A restriction request is not recognised at all. A rectification is applied to one system and not the others. Each is a failure to honour a right, with the same consequences as ignoring a DSAR.
- Data Tagging Inconsistencies
-
Data tagging is the application of classification labels , sensitivity tiers, data categories, handling requirements , to data elements across the systems where they exist. Consistent tagging ensures that a data element carries the same classification and corresponding controls regardless of which system it resides in.
data tagging inconsistency matters for TPRM because it means that data protection controls applied to the data's primary system do not necessarily apply to the same data in secondary systems , and secondary systems may have significantly broader access populations.
- Data Tagging Inconsistencies: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: label propagation mechanism description or gap acknowledgment; canonical classification scheme documentation covering all systems; cross-system classification consistency validation evidence.
- Data Usage Monitoring
-
Data usage monitoring is the capability to observe how data is actually being processed in a vendor's environment , what queries are run against it, what pipelines consume it, what products reference it, and whether its actual use is consistent with the contractual use specification.
data usage monitoring matters for TPRM because it is the mechanism that converts a DPA from a statement of authorized use into an enforceable governance instrument.
- Data Usage Monitoring: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: internal usage monitoring confirmation , query logs and pipeline attribution; ML training data monitoring description; scope violation detection capability description.
- DDoS Protection and Vendor Resilience
-
DDoS protection and resilience matter for TPRM because vendor platform availability is a direct dependency for enterprise customers whose operations rely on that platform.
DDoS protection and resilience matter for TPRM because vendor platform availability is a direct dependency for enterprise customers whose operations rely on that platform.
- DDoS Protection and Vendor Resilience: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: DDoS mitigation provider and capacity; customer notification procedure and timeline; SLA coverage for DDoS-related outages.
- Delegated Admin Risks
-
Delegated administration is a cloud platform feature that allows one organization (a partner or managed service provider) to administer another organization's cloud environment on their behalf , the partner's staff can access the customer's tenant with administrative privileges using their own organizational credentials, without being cre
delegated admin risks matter for TPRM because delegated admin relationships represent one of the highest-privilege access grants an organization can provide to a vendor , administrative access to an entire cloud tenant governed under the vendor's security policies rather than the customer's.
- Delegated Admin Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: current operational justification for each delegated admin relationship; partner staff MFA policy for delegated admin sessions; GDAP role specification if Microsoft partner relationship.
- Deletion versus destruction
-
Deletion removes data from active systems so that it is no longer available in normal operation. Destruction renders it unrecoverable everywhere it exists, including backups, replicas, snapshots, logs, analytics exports and caches. An erasure request is satisfied by the first and audited against the second.
backups are where deletion fails. Data removed from the production database persists in nightly backups for their retention period, in replicas until they sync, in data warehouse extracts until the next full load, and in logs until they roll. A controller who confirmed deletion while all of those still hold the data has made a statement that is not true.
- Dependency (SCA) Blind Spots
-
Software Composition Analysis is the practice of identifying and assessing the open-source and third-party libraries included in an application's dependency tree , mapping what components the application depends on, what known vulnerabilities exist in those components, and what license obligations they create.
Log4Shell demonstrated at scale what third-party risk practitioners had understood theoretically: a vendor's security posture for the applications they deliver is substantially determined by the security posture of every library in their dependency tree, including dependencies they did not choose and may not know exist.
- Dependency (SCA) Blind Spots: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: confirmation of transitive dependency coverage with tool name and scan scope description; SBOM in CycloneDX or SPDX format, current within the last release cycle; mean time to awareness commitment for critical dependency CVEs , a timeframe, not a process description.
- Dependency Confusion Attacks
-
Dependency confusion matters for TPRM because it is a supply chain attack that your vendors may be vulnerable to , particularly software vendors and development tool providers who use internal package registries alongside public dependencies.
dependency confusion matters for TPRM because it is a supply chain attack that your vendors may be vulnerable to , particularly software vendors and development tool providers who use internal package registries alongside public dependencies.
- Dependency Confusion Attacks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: internal package name reservation on public registries; build environment isolation for external network access; a vendor who confirms secure build practices should be asked specifically about dependency confusion mitigation. Build environment security includes registry configuration , not only code review and static analysis.
- Dependency Pinning vs Floating Versions
-
Dependency pinning matters for TPRM because floating version specifications in vendor codebases mean that the software a vendor delivered yesterday may differ from the software they build tomorrow , even if no application code was changed. For supply chain security, reproducibility of dependency resolution is a foundational control.
dependency pinning matters for TPRM because floating version specifications in vendor codebases mean that the software a vendor delivered yesterday may differ from the software they build tomorrow , even if no application code was changed.
- Dependency Pinning vs Floating Versions: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: lock file existence in production repositories; lock file enforcement in CI/CD pipeline; automated dependency update tooling , Dependabot or Renovate.
- Dependency Update Automation
-
Dependency update automation quality matters for TPRM because the presence of automation is the easy confirmation , confirming Dependabot is configured takes seconds. Whether that automation is actually reducing dependency vulnerability exposure requires understanding merge rates, backlog aging, and security update prioritisation.
dependency update automation quality matters for TPRM because the presence of automation is the easy confirmation , confirming Dependabot is configured takes seconds.
- Dependency Update Automation: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: security update PR creation and merge rate; security vs non-security update prioritisation configuration; a vendor who confirms Dependabot or dependency update automation should be asked for the merge rate. Automation configured is the tool. Merge rate is the effectiveness metric. 847 PRs generated and 23 merged is not dependency security management.
- Deployment Environment Isolation
-
Deployment environment isolation matters for TPRM because pre-production environments that handle production data or share credentials with production systems create security risks that are not captured in production environment security assessments.
deployment environment isolation matters for TPRM because pre-production environments that handle production data or share credentials with production systems create security risks that are not captured in production environment security assessments.
- Deployment Environment Isolation: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: data sanitisation process and validation confirmation; separate credential documentation for environment tiers; a vendor who confirms production data access controls should be asked about pre-production environment data and credential isolation. Production controls protect production data. Environment isolation determines whether that data reaches environments where the same controls do not apply.
- Deployment Rollback and Recovery Capabilities
-
Rollback capabilities matter for TPRM because they determine how quickly a vendor can recover from a problematic deployment , including a deployment that contains a vulnerability or a supply chain compromise.
rollback capabilities matter for TPRM because they determine how quickly a vendor can recover from a problematic deployment , including a deployment that contains a vulnerability or a supply chain compromise.
- Deployment Rollback and Recovery Capabilities: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: recent rollback execution example with time measurement; database migration reversibility assessment process; feature flag infrastructure for complex rollback scenarios.
- Description criteria
-
The description criteria, published as DC section 200, govern what a system description must contain: the services provided, the principal service commitments and system requirements, the components of the system, relevant aspects of the control environment, incidents during the period, and the criteria used. Every SOC 2 description follows this structure.
it explains why system descriptions from unrelated vendors read as though they were written from the same template. They were, in the sense that the same criteria shaped them. It also means a missing element is noticeable: a description with no incidents section, or no statement of service commitments, has omitted something the criteria require.
- Detection Blind Spots
-
Detection blind spots are the portions of a technology environment that are not covered by the current security monitoring configuration , the systems, services, and environments that generate security-relevant events but are not configured to forward those events to the monitoring platform where the SOC can detect and respond to them.
detection blind spots matter for TPRM because a vendor's monitoring coverage is only as comprehensive as their most recent configuration audit , and in rapidly growing environments, the gap between the configuration and the actual environment may represent a significant fraction of the attack surface.
- Detection Blind Spots: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: environment inventory vs monitoring configuration comparison; coverage percentage for current environment; monitoring configuration deployment process confirmation.
- Detection Engineering Gaps
-
Detection engineering is the discipline of designing, building, testing, and maintaining the detection logic , correlation rules, behavioural analytics, and anomaly detection policies , that enable a SIEM and SOC to identify malicious activity in a specific environment.
detection engineering gaps matter for TPRM because the SOC's detection capability is only as good as the rules that have been built and maintained.
- Detection Engineering Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: custom versus default rule ratio; industry-specific rule count and technique coverage; rule testing cadence and last test date.
- Detection vs Prevention Balance
-
The detection versus prevention balance problem in vendor security assessment is the challenge of understanding whether a vendor's clean breach record reflects effective prevention capability or simply low attack exposure. Both produce the same breach record.
detection versus prevention balance matters for TPRM because supply chain targets are specifically selected for their access to high-value data , and vendors who hold or process high-value data will face increasing attack pressure as their data value becomes known to threat actors.
- Detection vs Prevention Balance: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: near-miss history , significant prevented attacks; email security block rate and volume; vulnerability patch timelines for critical vulnerabilities.
- Dev vs Prod Parity Issues
-
Development-production parity is the principle that development, staging, and production environments should be as similar as possible to prevent issues from arising in production that were not caught in testing.
for TPRM practitioners, dev-prod parity is the reliability problem underlying every vendor security testing result.
- Dev vs Prod Parity Issues: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: penetration test scope documentation confirming production environment testing or documented production parity verification for staging; production-specific configuration disclosure , any settings, features, or integrations in production not covered by security testing; production change management process documentation including security review and testing synchronization.
- Device Trust for Vendor Access
-
Device trust is the component of access governance that evaluates the security posture of the endpoint from which access is being requested , determining whether the device is managed by the organization (or a trusted organization), meets defined compliance requirements, has current endpoint protection, and is capable of responding to org
device trust matters for TPRM because vendor access to customer environments means that session data, downloaded files, and cached content from customer systems reside on vendor engineer devices , and the security of that data once it reaches the vendor's endpoint depends entirely on the vendor's endpoint security posture.
- Device Trust for Vendor Access: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: MDM enrollment confirmation for devices used for customer access; device compliance policy documentation , patch level, endpoint protection, encryption; remote wipe capability and response time confirmation.
- DevSecOps for Legacy Systems
-
Legacy system DevSecOps matters for TPRM because enterprise vendors frequently maintain legacy systems that continue to process critical business data while the vendor invests in modernisation.
legacy system DevSecOps matters for TPRM because enterprise vendors frequently maintain legacy systems that continue to process critical business data while the vendor invests in modernisation.
- DevSecOps for Legacy Systems: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: legacy delivery process security testing , dependency scanning, SAST; legacy security track during migration; legacy security debt inventory and remediation plan.
- DevSecOps Maturity Model for TPRM Assessment
-
DevSecOps maturity assessment matters for TPRM because the quality of a vendor's software , specifically the density of undetected vulnerabilities in shipped code , is directly correlated with the effectiveness of their DevSecOps programme, not just its sophistication of description.
devSecOps maturity assessment matters for TPRM because the quality of a vendor's software , specifically the density of undetected vulnerabilities in shipped code , is directly correlated with the effectiveness of their DevSecOps programme, not just its sophistication of description.
- DevSecOps Maturity Model for TPRM Assessment: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: hard-blocking vs advisory gate count; current critical and high finding backlog; net backlog change last quarter.
- Digital Trust Common Framework DTCF
-
The association's common control framework: normalised objectives mapped to the frameworks practitioners work against, published free.
Mappings are graded, and an empty cell is recorded as a deliberate absence with its reason rather than hidden.
See also: Scope, Control owner
- Direct marketing rules
-
Electronic direct marketing in Europe is governed by the ePrivacy Directive, implemented nationally as PECR in the UK and equivalents elsewhere, alongside GDPR rather than replaced by it. ePrivacy sets rules for unsolicited email, SMS and calls, generally requiring prior consent for individuals with a soft opt-in exception for existing customers, and applying different rules to corporate subscribers.
teams satisfy GDPR by identifying a lawful basis and assume marketing is covered. It is not. GDPR governs the processing of the personal data; ePrivacy governs the sending of the message, and both must be satisfied. A legitimate interests basis under GDPR does not override an ePrivacy consent requirement.
- DNS Security and Vendor Risk
-
DNS security matters for TPRM because DNS-layer controls are a cost-effective prevention and detection capability that significantly reduces the effectiveness of phishing and malware C2 communication , both of which are primary attack vectors against vendor employees.
DNS security matters for TPRM because DNS-layer controls are a cost-effective prevention and detection capability that significantly reduces the effectiveness of phishing and malware C2 communication , both of which are primary attack vectors against vendor employees.
- DNS Security and Vendor Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: DNS filtering with threat intelligence confirmation; a vendor who confirms network security should be asked about DNS security. DNS filtering blocks phishing and C2 resolution at the network layer. DNS logging provides visibility for compromise indicators. Both are network-layer controls that significantly reduce attack effectiveness at low cost.
- Due Diligence Depth vs Vendor Tier
-
Due diligence depth matters because the risk a vendor represents is not reduced by collecting evidence that confirms the vendor's controls are documented , it is reduced by understanding whether those controls are effectively implemented.
due diligence depth matters because the risk a vendor represents is not reduced by collecting evidence that confirms the vendor's controls are documented , it is reduced by understanding whether those controls are effectively implemented.
- Due Diligence Depth vs Vendor Tier: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SOC 2 report with tests performed descriptions; scope inclusions and exclusions clarification; bridge letter for currency if report is more than six months old.
- Due diligence questionnaires
-
A due diligence questionnaire is a set of questions sent to a vendor about their security and privacy practices. Its answers tell you what the vendor is willing to commit to in writing, which is useful, and what practices they say exist, which is a claim. It does not tell you whether a control operates, because the vendor is describing intent and nobody has tested it.
questionnaires are the most used and least examined instrument in the whole discipline. Hundreds of questions go out, answers return weeks later, someone scores them, and afterwards nobody can say what was established beyond the fact that the vendor completes questionnaires. Yet buyers keep sending them, because they are the one thing that scales.
E
- Employee monitoring
-
Workplace monitoring, whether of email, web use, location, keystrokes or productivity, is processing of personal data and engages data protection law fully. Consent is generally an invalid basis for it, because the imbalance of power between employer and employee means consent cannot be freely given. Legitimate interests, with a documented assessment and genuine transparency, is the usual defensible route, and some jurisdictions add specific employment law requirements.
monitoring tools are frequently deployed under a consent clause in the employment contract, on the theory that signing the contract was consent. It was not, and regulators have said so repeatedly. The employee had no realistic choice, and consent without choice is not consent.
- Encryption at Rest vs In Use
-
Encryption at rest confirmation is one of the most frequently cited security controls in vendor questionnaire responses , it is visible, auditable, and documented in SOC 2 reports.
encryption at rest confirmation is one of the most frequently cited security controls in vendor questionnaire responses , it is visible, auditable, and documented in SOC 2 reports.
- Encryption at Rest vs In Use: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: key management architecture description , KMS service, key access segregation from data access; in-use protection description , access controls, field-level encryption, or confidential computing for highest-sensitivity data; TLS coverage confirmation for internal service communication.
- EU AI Act risk tiers
-
The EU AI Act sorts AI systems by use rather than by technique. Prohibited practices are banned outright. High-risk uses, listed in its annexes and including employment, credit, education, essential services and law enforcement, carry substantial obligations. Systems with transparency obligations, such as those interacting with people or generating content, must disclose. Everything else carries few obligations beyond ordinary law.
the tier decides everything, and most organizations assess as though the question did not exist. A model that ranks warehouse restocking and one that ranks job applicants have similar architecture and entirely different obligations, because the second is a high-risk use. Your role matters too: providers who place a system on the market carry more than deployers who use one, though deployers of high-risk systems carry real duties, including human oversight and monitoring.
- Evidence
-
An artefact showing that a control operated: dated, attributable, complete and produced when the control ran.
Contemporaneous is the property broken most often and in good faith. Evidence assembled when it is requested costs weeks and looks like what it is.
Taught in GRC-220 · See also: Population and sample, Control owner
- Evidence calendars
-
An evidence calendar lists, per control, the artefact that proves it ran, the system it comes from, the named producer, the cadence, the retention and the storage location. Evidence for a Type II report or a certification has to cover the whole period, so it is produced monthly and quarterly during the window rather than gathered at the end, and the calendar is what makes that happen.
most audit pain is evidence pain. The controls usually work. What fails is the ability to show they worked, for the period, from a source the auditor can trust, without three weeks of people digging through systems. A request list of forty items arrives, each goes to a control owner who exports something and screenshots something else, half the artefacts have no date, and two were produced this week for a control that was supposed to run quarterly.
- Evidence sufficiency
-
Sufficient evidence shows what happened, when it happened, in which system, by whom, and covers the period being tested. It is complete enough that the auditor does not have to take anyone's word for the parts it does not show.
most rejected evidence is not wrong. It is incomplete. A screenshot with no timestamp, no system identifier and no indication of scope proves that something existed at an unknown moment on an unknown screen. It cannot be tied to the control, the period or the population, so it cannot support a conclusion.
- Evidence vs Attestation
-
Attestation is a statement made by an authorised individual asserting that a condition is true , typically based on their knowledge, belief, or understanding of the organization's policies, standards, and practices.
evidence versus attestation matters for TPRM because the security risk created by a vendor relationship is determined by the actual configuration of the systems handling customer data , not by the organization's standard or the CISO's belief about compliance with that standard.
- Evidence vs Attestation: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: system-level encryption configuration records or CSPM output; list of all systems holding customer data with their encryption configuration; exceptions documentation , any systems not matching stated standard.
- Exception Management Abuse
-
Exception management is the governance mechanism for acknowledging that specific operational circumstances create genuine constraints that prevent implementation of a security baseline requirement, and for formally managing those situations with compensating controls, documented residual risk acceptance, and defined timelines for either r
exception management abuse matters for TPRM because vendor security baselines confirmed through questionnaires may have extensive exception registers that systematically carve out significant portions of the environment from baseline requirements.
- Exception Management Abuse: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: exception age distribution and recurrence count; baseline compliance rate for critical requirements; implementation roadmaps for deferral exceptions.
- Exception processes
-
An exception is a decision that a control or a policy will not apply in a specific case for a specific period. It needs everything an acceptance needs, plus a scope and a review before expiry. The pathology is the standing exception: granted for a six-month migration, never revisited, still in force four years later and now relied upon by systems built after it.
a control programme without an exception route produces two outcomes, and both are bad. People route around the control quietly, or they stop and the business is blocked. The exception process is what lets the control hold while the genuine edge case is handled visibly, with a name, a reason and a date.
- Exception remediation and management response
-
Where a Type II report describes an exception, management may include a response: what happened, why, what was done about it, and when. The response is management's, not the auditor's, and the auditor reports it without testing it.
the response tells you more about the organization than the exception does. A specific, dated remediation with a named owner and a control change reads very differently from a paragraph of reassurance, and the difference is a direct signal of how the organization treats its own failures.
- Exceptions
-
An exception is an instance where a control did not operate as described during the observation period. A quarterly access review that was performed late. A terminated user whose access outlived them by a week. A change deployed without the recorded approval. The report describes the exception, the auditor's testing, and management's response.
exceptions are normal. Any organization operating controls for twelve months will miss something, and a report that describes what was missed and what was done about it is doing exactly what a report is for. The number of exceptions matters less than what they are and how management responded.
F
- False Positives vs Ignored Risks
-
False positive governance in vendor security programs is directly relevant to TPRM because it determines what the vendor's security tooling is actually finding and acting on versus what it is finding and dismissing.
false positive governance in vendor security programs is directly relevant to TPRM because it determines what the vendor's security tooling is actually finding and acting on versus what it is finding and dismissing.
- False Positives vs Ignored Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: suppression rate data by severity level , what percentage of findings at each severity are suppressed versus remediated; suppression approval workflow documentation confirming security review requirement for high and critical findings; penetration test to SAST correlation confirmation , whether any penetration test findings matched previously suppressed SAST findings.
- Firewall Rule Hygiene and Vendor Networks
-
Firewall rule hygiene matters for TPRM because a vendor's stated network security architecture is only as accurate as their firewall rule set reflects it.
firewall rule hygiene matters for TPRM because a vendor's stated network security architecture is only as accurate as their firewall rule set reflects it.
- Firewall Rule Hygiene and Vendor Networks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: firewall rule count and last review date; a vendor who confirms firewall security should be asked about rule hygiene. Firewall security is the combination of the firewall architecture and the quality of the rules implementing it. 3,847 rules with unknown justification is not a firewall that accurately implements an intended security architecture.
- Forensics Access Challenges
-
Forensics access challenges are the practical, legal, and contractual obstacles to obtaining the forensic evidence , logs, forensic images, memory captures, network traffic records , needed to conduct an independent investigation of a security incident that occurred in a vendor's environment.
forensics access challenges matter for TPRM because customers who cannot conduct independent forensic investigation of a vendor breach cannot determine their own exposure with the specificity needed for regulatory filings, insurance claims, and legal proceedings.
- Forensics Access Challenges: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: forensic access procedure in breach scenario; evidence preservation commitment before remediation; litigation hold limitation for customer investigation purposes.
- Fourth party
-
Your vendor's vendor: the providers behind the companies you contract with.
You did not choose them and cannot see them without looking. The same few names sit behind many vendors, so apparent diversification often is not.
Taught in TPR-250 · See also: Concentration risk, Subservice organisation
- Fourth-party risk
-
A fourth party is your vendor's vendor: the cloud their software runs on, the payment processor inside their billing tool, the transcription service inside their support platform. You did not choose them, you have no contract with them, and an outage or a breach at one of them reaches you through a company you have never heard of.
two problems live here and they need different answers. Visibility, where you cannot say who is in the chain until something breaks. And concentration, where many of your supposedly independent vendors turn out to run on the same handful of providers, so one failure arrives through several doors at once and your diversification was a set of logos over one platform.
- Fourth-Party Risk Blindness
-
Fourth-party risk matters because the attack surface of the enterprise extends through its vendors' supply chains, not just through the vendors themselves.
fourth-party risk matters because the attack surface of the enterprise extends through its vendors' supply chains, not just through the vendors themselves.
- Fourth-Party Risk Blindness: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: complete subprocessor list with function for each; infrastructure and authentication provider identification; vendor's own third-party risk programme confirmation.
G
- Geopolitical Risk in Vendor Selection
-
Geopolitical risk matters because it creates a category of vendor risk that traditional technical security assessments do not address , the risk arising from the legal environment in which the vendor's personnel, corporate structure, and operations exist. Technical controls protect data from unauthorised access by attackers.
geopolitical risk matters because it creates a category of vendor risk that traditional technical security assessments do not address , the risk arising from the legal environment in which the vendor's personnel, corporate structure, and operations exist.
- Geopolitical Risk in Vendor Selection: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: personnel jurisdiction disclosure for data access roles; government access law analysis for disclosed jurisdictions; legal framework for customer notification if government access occurs.
- GitOps Security Patterns
-
GitOps security matters for TPRM because GitOps implementations that grant broad operator permissions create a direct path from Git repository merge access to production cluster control.
gitOps security matters for TPRM because GitOps implementations that grant broad operator permissions create a direct path from Git repository merge access to production cluster control.
- GitOps Security Patterns: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: gitOps repository access controls and merge approval; a vendor who confirms GitOps deployment should be asked about operator RBAC. GitOps operator permissions define the blast radius of GitOps repository merge access. Cluster-admin operator with open merge access creates cluster-admin deployment authority for anyone with merge access.
- Global Privacy Control GPC
-
A browser signal indicating that the user opts out of the sale or sharing of their personal information.
In several US states a received signal is a valid opt-out. It arrives as a header, so it has to be handled by code before any tag fires, not by a banner.
Taught in PRV-230 · See also: Sale and sharing, Consent management platform
- Governance Accountability Gaps
-
Governance accountability is the personal sense of obligation and ownership , felt by a specific individual , to ensure that a vendor relationship is governed effectively, that risks are managed, and that when things go wrong, decisive action is taken without waiting for permission or instruction.
governance accountability gaps matter for TPRM because effective vendor risk management , particularly in high-stakes situations like vendor security incidents , requires individuals who personally own the outcome and act decisively.
- Governance Accountability Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: named individual with whole-relationship accountability; direct contact information , mobile number for after-hours incident notification; confirmation they are aware of contractual notification obligations.
- Governance Ownership Ambiguity
-
Governance ownership ambiguity in vendor relationships is the absence of a single accountable owner for the overall vendor relationship , the individual or role who is responsible for ensuring the relationship operates as intended, that risks are managed across all dimensions, and that escalation and response are coordinated when issues a
governance ownership ambiguity matters for TPRM because complex vendor relationships inevitably encounter situations that require coordinated response , security incidents, service failures, regulatory enquiries, contract disputes, and material vendor changes.
- Governance Ownership Ambiguity: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: named accountable owner for the customer relationship; incident notification routing process , how notifications reach the accountable owner; escalation timeline for security incidents to customer notification.
- GRC Tooling Limitations
-
GRC tooling limitations are the gaps between what a GRC platform is technically capable of managing and what the risk management programme actually uses it to manage.
GRC tooling limitations matter for TPRM because the GRC platform is increasingly used as the evidence of risk programme maturity , in regulatory examinations, in board reporting, and in vendor due diligence documentation.
- GRC Tooling Limitations: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: GRC programme input process documentation; informal risk channel formalisation records; platform coverage versus risk landscape assessment.
H
- Hardcoded Credentials in Vendor Apps
-
Hardcoded credentials are authentication values , usernames, passwords, API keys, cryptographic keys, tokens, or certificates , that are embedded directly in an application's source code, compiled binary, firmware, configuration file, or deployment script in a way that cannot be changed through normal configuration mechanisms.
hardcoded credentials in vendor applications represent a category of risk that sits entirely outside the customer's control and entirely inside the vendor's code , a combination that creates a specific and uncomfortable governance position.
- Hardcoded Credentials in Vendor Apps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SAST configuration evidence confirming credential detection rules are active and applied to the full codebase; default credential documentation , complete disclosure of any defaults that ship with the application and the change mechanism available to customers; penetration test scope confirmation explicitly including hardcoded credential discovery.
- High-risk AI systems
-
A high-risk AI system, in the EU AI Act's terms, is one used in a context the Act lists in its annexes: recruitment and worker management, creditworthiness, education and exam scoring, access to essential services, law enforcement, migration, and the administration of justice, among others. The list is about what the system decides and about whom. A simple model in a high-risk use is high-risk; a sophisticated one summarising your meeting notes is not.
most organizations are deployers of systems bought from vendors, and that is the case most often assessed as though no duties apply. A deployer of a high-risk system must ensure human oversight by competent people, monitor the system's operation, keep logs, use it according to the provider's instructions, and inform the people affected. None of that is a security control, and none of it appears on the vendor's SOC 2.
- Human oversight
-
Human oversight is the design that lets a person intervene in an AI system's decisions, and it is real only under four conditions. The reviewer sees enough to judge, meaning the output and the factors behind it rather than a score alone. They have time, measured against the actual handling target. They have competence for the decision. And overriding is professionally safe, meaning they are not measured in a way that punishes it.
a human reviews all outputs is the most common sentence in AI governance documentation and one of the least informative. Remove any one of the four conditions and oversight becomes a signature. The fourth is the one organizations rarely examine and it is usually the binding constraint: a reviewer measured on cases per hour will not spend two minutes disagreeing with a model.
I
- Identity Anomaly Detection Gaps
-
Identity anomaly detection is the capability to identify access patterns that deviate from established normal behaviour , detecting authentication events, access patterns, data transfers, and session characteristics that are inconsistent with a user's baseline behaviour or that represent known attack patterns.
identity anomaly detection matters for TPRM because vendor staff accessing customer environments create an identity behaviour pattern that should be detectable as anomalous when it deviates from normal support or operational activity.
- Identity Anomaly Detection Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: attack scenario detection analysis , which signals the described attack would trigger; UEBA deployment with individual behavioural baselines; vendor access baseline establishment process.
- Identity Attack Surface Expansion
-
Identity attack surface is the aggregate of all authentication endpoints, identity systems, and credential stores that an organization operates , every system where an attacker could attempt to authenticate as a valid user and gain access.
identity attack surface expansion matters for TPRM because vendors who have grown through acquisitions, SaaS adoption, and cloud migration may have a significantly larger identity attack surface than their centralized IdP description suggests.
- Identity Attack Surface Expansion: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: complete identity system inventory beyond corporate IdP; authentication policy comparison across all identity systems; saaS authentication configuration , corporate IdP vs local directory.
- Identity Compromise Blast Radius
-
Blast radius is the scope of systems, data, and capabilities that become accessible to an attacker upon compromising a specific identity credential. It is the answer to the question: if this credential were stolen right now, how much could an attacker do with it?
blast radius matters for TPRM because multi-customer vendor relationships create the possibility of single-credential supply chain attacks , where compromising one vendor identity provides simultaneous access to multiple customer environments.
- Identity Compromise Blast Radius: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: maximum customer environment access scope per credential; blast radius threshold policy if defined; JIT access for high-blast-radius credentials.
- Identity Federation Trust Risks
-
Identity federation is a trust relationship between identity providers that enables users from one organization to access resources in another organization using their home organization's credentials.
identity federation trust risks matter for TPRM because they represent the IAM equivalent of the supply chain attack , the adversary who cannot breach the target directly compromises a trusted partner and uses the trust relationship to gain access.
- Identity Federation Trust Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: partner IdP MFA policy documentation , enforcement level and any exceptions; partner IdP compromise notification process with timeline; identity lifecycle governance , account review cadence and deprovisioning process.
- Identity Governance Gaps
-
Identity governance is the program of policies, processes, and tools that ensure digital identities , user accounts, service accounts, API credentials, and other access principals , are created appropriately, maintained proportionately, and retired timely throughout their operational life.
identity governance gaps matter for TPRM because they reveal a systematic difference in governance maturity between how a vendor manages its own employee identities and how it manages the identities of the vendor staff accessing customer environments.
- Identity Governance Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: IGA coverage scope documentation , identity populations included; vendor account inventory with last reconciliation date; access review completion rate data by identity population.
- Identity Logging Gaps
-
Identity logging is the comprehensive capture of all identity-related events in an environment , authentication attempts (both successful and failed), authorisation decisions (access granted and denied), session lifecycle events (session creation, extension, expiry, and termination), privileged action records (what privileged users did du
identity logging gaps matter for TPRM because vendors who access customer environments need comprehensive identity logging to detect attacks against their own environments before those attacks reach customer data.
- Identity Logging Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: identity log event scope documentation , event types captured; failed authentication logging confirmation with SIEM alerting; log retention period calibrated to investigation requirements.
- Identity Proofing of Vendors
-
Identity proofing is the process of verifying that the individual requesting access or for whom access is being requested is who they claim to be , establishing a reliable binding between a digital identity (an account and credential) and a specific real-world person with a confirmed identity.
identity proofing of vendors matters for TPRM because the security properties of vendor access , least privilege, individual accountability, behavioral monitoring , all depend on the assumption that the account holder identity is accurate.
- Identity Proofing of Vendors: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: employment verification confirmation for nominated staff; authorized nomination process documentation , who can nominate and at what level; subcontractor disclosure policy and access governance.
- Identity Trust Assumptions
-
Identity trust assumptions are the implicit beliefs about the security posture and trustworthiness of vendor identity systems and access practices that underpin the access grants, access controls, and monitoring configurations applied to vendor relationships.
identity trust assumptions matter for TPRM because the access controls, monitoring configurations, and risk mitigations applied to vendor identity access are calibrated to the vendor's assessed trust level.
- Identity Trust Assumptions: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: organizational change disclosure , acquisitions, leadership changes, infrastructure migrations; security incident disclosure including below-threshold incidents; continuous security posture monitoring data.
- Identity-Based Lateral Movement
-
Identity-based lateral movement is the technique of traversing an environment by chaining legitimate identity and permission steps , using one set of valid credentials to obtain another, using access to one resource to discover or access credentials for another, and progressively building toward a high-value target through a sequence of i
identity-based lateral movement matters for TPRM because vendor environments with access to customer systems are precisely the environments where a credential compromise could cascade through permission chains to reach customer data or infrastructure.
- Identity-Based Lateral Movement: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: attack path analysis tool and last analysis date; lateral movement path remediation records; credential store access restriction documentation.
- Incident classification
-
Incident classification is the severity scale that decides, in the first minutes, who is woken, how often status is issued, whether legal is engaged and whether an engineer may take a system offline without asking. Three or four levels, each with objective triggers the person who finds the problem can apply, and each with a defined response.
the first hour of an incident is spent on questions that could have been answered in advance, and the argument about whether this is serious enough to escalate is the most expensive of them. A scale without triggers becomes that argument at the worst moment. A scale with triggers converts it into a lookup, and the response follows automatically.
- Incident Communication Breakdowns
-
Incident communication breakdowns in vendor relationships are the failures in the flow of specific, technically useful information from the vendor's IR team to the customer's IR team during a shared incident , breakdowns that impair the customer's ability to understand their own exposure, complete their own regulatory obligations, and con
incident communication breakdowns matter for TPRM because the customer's ability to complete their own regulatory obligations , HIPAA breach risk assessment, GDPR notification, financial services incident reporting , depends on obtaining specific technical information from the vendor within the applicable regulatory timelines.
- Incident Communication Breakdowns: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: named IR contact for technical communication during incidents; commitment to provide specific technical details within defined timeline; process for IR-to-IR communication bypassing legal review delay.
- Incident Escalation Across Vendors
-
Incident escalation across vendors is the challenge of ensuring that security incidents at vendor environments that affect customer data are escalated to the customer , and to regulatory authorities , on timelines that satisfy the customer's regulatory obligations, not just the vendor's internal incident management SLAs.
incident escalation across vendors matters for TPRM because the customer's regulatory obligations are determined by law, not by the vendor's incident classification.
- Incident Escalation Across Vendors: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: incident classification criteria for customer-relevant systems; preliminary notification timeline from detection; confirmation that notification SLA is calibrated to customer's regulatory deadline.
- Incident Ownership Confusion
-
Incident ownership confusion is the absence of a single individual or team with clear, pre-assigned authority to make specific high-stakes decisions during a security incident.
incident ownership confusion matters for TPRM because the vendor breach notification starts the customer's regulatory clock , and the customer's escalation loop is the mechanism that determines how much of that clock is consumed before a notification decision is made.
- Incident Ownership Confusion: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: named decision owner for customer notification decision; named decision owner for regulatory notification decision; after-hours contact information for decision owners.
- Incident Playbook Gaps
-
Incident playbook gaps are the deficiencies in scenario-specific incident response procedures that prevent effective execution under actual incident conditions , gaps in completeness, accessibility, accuracy, and operational specificity that cause delays, errors, or failures when responders attempt to execute the playbook during an active
incident playbook gaps matter for TPRM because the quality of a vendor's incident response during a breach affecting customer data depends on how effectively their playbooks execute under actual incident conditions , which may be 2am on a Saturday, with an on-call analyst on their personal device, without access to the network team's wiki
- Incident Playbook Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: operability test date and method; gaps identified in operability testing; self-contained vs external-reference procedure design.
- Incident Response SLAs
-
Incident response SLAs in vendor contracts define the timing requirements for specific response actions , notification timelines, investigation update commitments, and remediation completion deadlines. SLA compliance is measured by whether actions occur within the defined timeframes.
IR SLAs matter for TPRM because they are the primary contractual mechanism for protecting the customer's response timeline , but SLAs that protect the timing without requiring the content that enables response protect the contractual relationship without protecting the customer's ability to actually respond.
- Incident Response SLAs: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: notification content requirements , what the notification will contain; scope confirmation SLA , when confirmed scope follows preliminary notification; a vendor who confirms a forty-eight-hour notification SLA should be asked what the notification will contain when it arrives. Timing is one dimension of the SLA. Content is the other. Both are required for the notification to enable the response it was designed to protect.
- Incident response under CC7
-
CC7 covers system operations: detecting and monitoring for anomalies, evaluating events, responding to incidents, and recovering from them. It also covers communicating incidents to affected parties. It is the criterion that asks whether you would notice something going wrong and what you would do about it.
auditors ask for the incidents that occurred during the period and trace them through the process. Having none is itself a question, because a year with no security events is more likely a year with no detection than a year with no attacks. The plan is tested against what actually happened.
- Information produced by the entity
-
Information produced by the entity, IPE, is any report, list or extract you generate and offer to the auditor as evidence. A user listing from the identity system. A change log from the ticketing tool. A spreadsheet of access review results. Before the auditor can rely on it, they must satisfy themselves it is complete and accurate.
this is why the auditor asks to see the query, the parameters, the date it was run and the system it came from, and sometimes to watch it being generated. A list that arrived by email with no provenance is a claim, not evidence, and validating it usually costs more than producing it properly would have.
- Infrastructure Drift Detection
-
Infrastructure drift matters for TPRM because the security posture of a vendor's production infrastructure is only as accurate as the IaC configuration that describes it , and drift means the actual posture may be less secure than the IaC documentation suggests.
infrastructure drift matters for TPRM because the security posture of a vendor's production infrastructure is only as accurate as the IaC configuration that describes it , and drift means the actual posture may be less secure than the IaC documentation suggests.
- Infrastructure Drift Detection: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: drift detection implementation and monitoring; last drift assessment date and findings; emergency change process with IaC codification requirement.
- Infrastructure Provisioning Security
-
Infrastructure provisioning security matters for TPRM because vendors who provision infrastructure automatically through CI/CD pipelines are giving those pipelines cloud provider credentials and infrastructure management capabilities.
infrastructure provisioning security matters for TPRM because vendors who provision infrastructure automatically through CI/CD pipelines are giving those pipelines cloud provider credentials and infrastructure management capabilities.
- Infrastructure Provisioning Security: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: state storage location with versioning and access logging confirmation; state access control documentation , who can read and write; plan review process for production changes.
- Infrastructure-as-Code Supply Chain Risk
-
IaC supply chain risk matters for TPRM because vendors who use infrastructure automation , increasingly the norm for cloud-native environments , are building their infrastructure on dependency chains that include public registry modules.
iaC supply chain risk matters for TPRM because vendors who use infrastructure automation , increasingly the norm for cloud-native environments , are building their infrastructure on dependency chains that include public registry modules.
- Infrastructure-as-Code Supply Chain Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: iaC scanning coverage including module content; internal vetted module registry or equivalent; a vendor who confirms IaC security practices should be asked about module supply chain coverage. IaC security scanning of own code confirms the wrapper. Full module content scanning covers the supply chain.
- Inherent and residual risk
-
Inherent risk is the exposure before any control operates. Residual risk is what remains after the controls you actually have, working as they actually work. The gap between them is what your control programme is worth, and confusing the two produces reports that are either alarming for no reason or reassuring for no reason.
a board asks how exposed the organization is, and the honest answer depends on which number you give. A vendor register that records inherent risk shows every critical supplier as red and tells nobody what to do. One that records only residual risk hides the fact that a cheap control is all that stands between a low score and a high one, which is exactly the thing a board should know.
- Inherent Risk Tiering
-
Inherent risk tiering is the process of classifying vendor relationships by their potential risk to the organization , before controls are assessed , based on objective characteristics of the relationship: the data they access, the services they provide, the systems they connect to, and the operational criticality they represent.
inherent risk tiering matters because without it, due diligence effort is allocated by administrative convenience rather than risk.
- Inherent Risk Tiering: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: specific tiering criteria with thresholds; tier-differentiated questionnaire or assessment scope; a vendor who confirms rigorous due diligence for all vendors should be asked about their tiering criteria. All vendors assessed the same way is either proportionality theatre or proportionality failure , depending on whether the questionnaire is calibrated to the highest or lowest risk tier.
- Inherent vs Residual Risk Confusion
-
The inherent versus residual risk framework matters because residual risk scores drive resource allocation , which vendors receive intensive monitoring, which receive lighter-touch oversight.
the inherent versus residual risk framework matters because residual risk scores drive resource allocation , which vendors receive intensive monitoring, which receive lighter-touch oversight.
- Inherent vs Residual Risk Confusion: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: assessment scope inclusions and exclusions; confirmation that interaction systems are in scope; control testing methodology for in-scope systems.
- Injection Vulnerabilities in Vendor Code
-
Injection vulnerabilities are a class of application security weakness that arises when an application incorporates untrusted data , typically user-supplied input , into a command or query in a way that allows the data to be interpreted as part of the command rather than as data to be processed by it.
injection vulnerabilities in vendor applications are particularly consequential from a third-party risk perspective because their impact is not limited to the vendor's own data , it extends to whatever the application can access, which in a multi-tenant SaaS context frequently includes every customer's data simultaneously.
- Injection Vulnerabilities in Vendor Code: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: penetration test scope documentation explicitly including injection coverage across recently added features and non-obvious input surfaces; injection finding history with remediation timelines and verification evidence , prior findings remediated and verified is more reassuring than no findings ever; SAST injection detection configuration confirmation with codebase coverage scope.
- Inquiry, observation, inspection, reperformance
-
There are four procedures an auditor uses to test a control. Inquiry is asking someone how it works. Observation is watching it happen. Inspection is examining the evidence it produced. Reperformance is doing it again independently and comparing the result. They are listed here in order of strength.
inquiry alone almost never suffices for a Type II, because being told a control operates is not evidence that it did. This is why "we explained the process to them" never closes an audit request, and why the auditor keeps asking for the artefact after the meeting.
- Insider Access at Vendors
-
Insider threat at vendors is the risk that vendor employees with legitimate access to customer data will misuse that access , for financial gain, competitive advantage, personal grievance, or external coercion , in ways that are not prevented by access controls because the access is authorized and not detected by perimeter security becaus
insider access at vendors matters for TPRM because the vendor relationship creates a class of people , vendor employees , who have authorized access to customer data but are not subject to the customer's HR processes, security training, behavioral monitoring, or employment controls.
- Insider Access at Vendors: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: behavioral analytics implementation description , UEBA applied to data access, baselines established, anomaly detection configured; data export monitoring confirmation , cumulative pattern detection with threshold calibration; insider threat incident history , detection events, investigation outcomes.
- Insider Threats at Vendors
-
Insider threats at vendors are the risk that vendor employees, contractors, or trusted users with legitimate access to systems containing customer data will misuse that access , intentionally, negligently, or through coercion , in ways that harm the customer.
insider threats at vendors matter for TPRM because the customer cannot directly monitor vendor employees' behaviour , the customer has no access to the UEBA that would detect the data engineer's query pattern change, no visibility into the export destination monitoring that would flag the Dropbox transfer, and no direct mechanism for dete
- Insider Threats at Vendors: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: UEBA deployment confirmation for staff with customer data access; minimum necessary access scoping documentation; DLP configuration for small batch export detection.
- Internet Exposure and Attack Surface Management
-
Internet exposure management matters for TPRM because vendor-confirmed external attack surfaces often differ from the actual externally accessible services due to shadow IT, misconfiguration, and the dynamic nature of cloud infrastructure.
internet exposure management matters for TPRM because vendor-confirmed external attack surfaces often differ from the actual externally accessible services due to shadow IT, misconfiguration, and the dynamic nature of cloud infrastructure.
- Internet Exposure and Attack Surface Management: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: scan vs documented inventory comparison.
- IPv6 Security , The Protocol Your Security Team May Have Forgotten
-
IPv6 Enabled: By Default on All Endpoints. IPv6 Monitoring: None.
IPv6 security matters for TPRM because IPv6 is enabled by default in most modern environments and attackers who are aware of this can use IPv6 communication paths to bypass IPv4 security controls.
- ISAE 3402 and international equivalents
-
ISAE 3402 is the international assurance standard for reports on controls at a service organization, issued by the IAASB rather than the AICPA, and broadly equivalent to a SOC 1. ISAE 3000 is the wider standard for assurance engagements other than audits of financial information, under which reports covering security and operational controls are issued outside the United States.
vendors in Europe, the UK, Australia and elsewhere frequently hold these rather than a SOC 2, and they are legitimate. A UK vendor with an ISAE 3000 report on security controls has been examined by an independent practitioner under a recognised standard, and rejecting it because it is not called SOC 2 is a mistake.
- ISO 27001 Statement of Applicability
-
The Statement of Applicability is the ISO 27001 document listing every control in the standard's Annex A, whether each applies to your organization, the justification, and its implementation status. It is required by the standard, referenced on the certificate, and it is the first document a certification auditor opens, because everything else in the audit follows from it.
the certificate tells you an organization is certified. The SoA tells you what that means: which controls are in the audit, which were excluded and why, and whether the exclusions are about relevance or convenience. A vendor who cannot produce their SoA on request has told you something about how the certification was obtained.
- ISO 42001
-
ISO 42001 is the management system standard for AI, structured like ISO 27001: clauses for context, leadership, planning, support, operation, evaluation and improvement, with an annex of controls specific to AI. It is certifiable, which means an accredited body can audit against it and issue a certificate with a scope statement.
buyers who ask for ISO 27001 for security are beginning to ask for ISO 42001 for AI, particularly where a product makes decisions about people. It also comes up internally as the way to give AI governance the same machinery security governance has: a scope, a risk assessment, a statement of applicability, internal audit and management review.
- IT general controls ITGC
-
Controls over access to programs and data, program changes, program development and computer operations.
If they fail, an auditor cannot rely on any automated control running on those systems, however well designed.
Taught in GRC-230 · See also: Statement of Applicability, Population and sample
J
- Joiner, mover, leaver
-
Joiner, mover, leaver is the process by which access is granted when someone starts, adjusted when they change role, and removed when they leave. Joiners are handled because someone needs to work. Leavers are handled, eventually, because an audit checks. Movers are where access accumulates, because adding access is a request somebody makes and removing the old access is nobody's task.
it is the control behind half the findings in any access audit, it is the mechanism most complementary user entity controls in vendor reports assume you operate, and it is where a terminated user's account changes bank details eighteen months after they left. Auditors test it by reconciling the HR feed against account creations and removals, and the reconciliation is where the gaps appear.
- Joint controllers
-
Where two or more organizations jointly determine the purposes and means of processing, they are joint controllers. GDPR requires them to determine their respective responsibilities in a transparent arrangement, including who handles data subject rights and who provides the privacy notice, and to make the essence of that arrangement available to data subjects.
joint controllership arises without anyone intending it. A co-branded campaign where both parties decide who to target. A shared platform where both parties shape what is collected. A referral arrangement where both use the same data for their own ends. The courts have found joint controllership in arrangements the parties described as something else.
- Just-in-Time Access vs Standing Access
-
Just-in-time access is a privileged access model in which elevated credentials are provisioned when needed for a specific task and automatically revoked when the task is complete or a defined time period expires.
JIT vs standing access matters for TPRM because vendor support and managed services arrangements frequently involve standing privileged access to customer environments , access that was provisioned for availability and represents continuous credential exposure for the duration of the vendor relationship.
- Just-in-Time Access vs Standing Access: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: JIT access confirmation or standing access justification documentation; access usage metrics , hours used vs hours credential is valid; PAM platform confirmation for JIT provisioning.
K
- Kubernetes Security in CI/CD
-
Kubernetes configuration security matters for TPRM because Kubernetes cluster misconfigurations are frequently the exploitable path that converts a container vulnerability into a cluster compromise.
kubernetes configuration security matters for TPRM because Kubernetes cluster misconfigurations are frequently the exploitable path that converts a container vulnerability into a cluster compromise.
- Kubernetes Security in CI/CD: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: kubernetes manifest scanning in CI/CD pipeline; pod security context enforcement mechanism; network policy implementation and default posture.
L
- Lateral Movement and Flat Networks
-
Lateral movement and flat networks matter for TPRM because the value of a supply chain attack is often determined not by the initial foothold but by the lateral movement capability the network architecture enables.
lateral movement and flat networks matter for TPRM because the value of a supply chain attack is often determined not by the initial foothold but by the lateral movement capability the network architecture enables.
- Lateral Movement and Flat Networks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: business function network segmentation description; lateral movement barriers between zones; internal penetration testing results for lateral movement paths.
- Lawful basis
-
GDPR requires a lawful basis for every processing activity, and provides six: consent, performance of a contract, compliance with a legal obligation, protection of vital interests, performance of a public task, and legitimate interests. One must apply before processing begins, and it must be identified and documented at the outset.
consent is the basis people reach for first because it sounds safest. It is the most demanding. It must be freely given, specific, informed and unambiguous, as easy to withdraw as to give, and it creates obligations that persist for as long as the processing does. Most B2B processing rests on legitimate interests or contract, and choosing consent by default builds a programme on the hardest foundation available.
- Least Privilege in Vendor Access
-
Least privilege is the principle that every entity , user, service account, application, or vendor integration , should be granted the minimum access required to perform its specific function, and no more.
least privilege in vendor access matters for TPRM because the blast radius of a vendor credential compromise is determined not by what the vendor needed but by what the vendor was granted.
- Least Privilege in Vendor Access: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: service account permission documentation , specific permissions with function justification; access scope review history , proportionality reviewed, not just existence confirmed; no admin-level access for non-admin functions.
- Legal hold litigation hold
-
An instruction suspending deletion of information relevant to a dispute, investigation or regulatory matter.
It overrides the retention schedule, and it needs a release: holds applied and never lifted become a permanent retention policy nobody decided on.
Taught in PRV-270 · See also: Retention schedule
- Legitimate interest in marketing
-
Whether an organization can send marketing to someone who never opted in depends on where the recipient is. In much of Europe, B2B email to a corporate address can rest on legitimate interests, subject to an opt-out. In Canada, CASL treats implied consent narrowly, ties it to an existing relationship, and puts an expiry on it. In the United States, CAN-SPAM permits sending with an opt-out and a postal address. The UK's PECR sits between them.
a single campaign list frequently spans all of these regimes, and a rule applied uniformly is wrong somewhere. The basis that is defensible for a German corporate address is not defensible for a Canadian one, and the penalty regimes differ by an order of magnitude.
- Legitimate interests LIA, balancing test
-
A lawful basis allowing processing necessary for a genuine interest, provided that interest is not overridden by the rights of the person.
It is a positive claim rather than a residual category, and the balancing test can come out against you. The assessment has to exist on paper.
Taught in PRV-201 · See also: Data protection impact assessment, Processor terms
- Legitimate interests and profiling
-
Profiling, the automated evaluation of personal aspects to predict behaviour, interests or characteristics, can rest on legitimate interests as a lawful basis. But the balancing test must account for the intrusiveness of the profile, the reasonable expectations of the individual, and the effect the profiling has on them. The more consequential the profile, the harder the balance is to strike.
behavioural scoring, propensity models and engagement predictions are routinely justified by an LIA that considers only the business benefit. The balancing test asks what the individual would expect, whether they would object if they knew, and what the profile does to their treatment. A profile that affects pricing, eligibility or the content someone sees is not a minor intrusion.
- LLM Integration Risks
-
LLM integration risks are the security and privacy risks arising from connecting large language models to enterprise data repositories , document libraries, databases, email systems, and knowledge bases , creating an AI system that can retrieve and process enterprise data in response to user queries.
LLM integration risks matter for TPRM because enterprise LLM deployments connected to sensitive document repositories create a new category of data access risk that traditional access controls are not designed to address.
- LLM Integration Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: service account vs user permission scope comparison; query monitoring for extraction patterns; a vendor who confirms LLM integration security should be asked about the service account permission scope and sensitive document category exclusion. Access controls protect direct document access. Service account retrieval scope and context window monitoring protect the indirect pathway the LLM creates.
- Log Ingestion From Vendors
-
Log ingestion from vendors is the challenge of obtaining, accessing, and retaining security log data from vendor environments for the purposes of incident investigation, compliance evidence, and ongoing threat detection in the customer's SIEM.
log ingestion from vendors matters for TPRM because security investigations increasingly require log evidence from vendor environments , and the availability of that evidence depends on retention policies and access arrangements that most vendor assessments confirm exist without verifying their adequacy for investigation purposes.
- Log Ingestion From Vendors: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: retention period by log category; investigation log access procedure and timeline; log forwarding capability for critical systems.
- Logging and evidence retention
-
Logging captures what happened: who signed in, what changed, what was accessed, what the system did. Retention decides how long that record survives. Together they are the evidence behind most other controls, since an access review, a change approval or an incident timeline is only demonstrable if the log that recorded it still exists when someone asks.
the audit finding is rarely that a control did not run. It is that nobody can show it ran for the period, because the log rolled after ninety days and the audit period is twelve months. It comes up in incidents, where the question of when access began cannot be answered because the log had aged out. And it comes up in privacy, where logs capturing request payloads turn out to hold personal data nobody had mapped.
- Logical access under CC6
-
CC6 covers logical and physical access: how access is provisioned, authenticated, authorised, reviewed and removed, how physical access to facilities is controlled, and how data is protected in transit, at rest and on disposal. It is the largest of the nine common criteria groups by some distance.
CC6 touches every system and every joiner, mover and leaver. The volume of evidence is larger than any other group, the population is constantly changing, and the failure modes are the ones that cause breaches. It produces more exceptions than any other group, and the auditor spends more time on it than on any other.
M
- Machine Identities vs Human Identities
-
Machine identities matter for TPRM because they are the primary pathway through which supply chain attacks propagate from vendor environments to customer environments. The SolarWinds attack compromised the build pipeline's machine identities.
machine identities matter for TPRM because they are the primary pathway through which supply chain attacks propagate from vendor environments to customer environments.
- Machine Identities vs Human Identities: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: machine identity count and inventory capability; secrets management platform deployment for machine credentials; machine identity review inclusion in governance cycle.
- Managed Service Provider TPRM Complexity
-
MSP TPRM complexity matters because MSP relationships are among the highest-risk vendor relationships the enterprise has , they involve broad system access, operational control of critical functions, and deep data exposure.
MSP TPRM complexity matters because MSP relationships are among the highest-risk vendor relationships the enterprise has , they involve broad system access, operational control of critical functions, and deep data exposure.
- Managed Service Provider TPRM Complexity: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: complete MSP tool stack list with access characterisation; direct access tool security certifications; security requirements applied to their tool vendors.
- Materiality in an attestation
-
Materiality is the threshold at which a deviation matters enough to affect the auditor's opinion or to be reported as an exception. It is a judgement the auditor makes, informed by the criterion affected, the nature of the deviation, and its likely effect on a reader's decisions.
it explains why a control that failed once in a sample of twenty-five may not appear as an exception, and why a single failure in a critical control may. It also explains why the report is not a complete log of everything that went imperfectly during the year. It is an opinion, shaped by judgement about what matters.
- Measuring DevSecOps Programme ROI
-
DevSecOps ROI measurement matters for TPRM because vendors who cannot demonstrate the security outcomes of their DevSecOps investment may be investing in security theatre rather than security improvement.
devSecOps ROI measurement matters for TPRM because vendors who cannot demonstrate the security outcomes of their DevSecOps investment may be investing in security theatre rather than security improvement.
- Measuring DevSecOps Programme ROI: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: MTTR tracking records and trend; pre-production vs post-production vulnerability discovery rate; cost-of-avoidance model for security programme.
- Metadata Exposure Risks
-
Metadata is data about data , the contextual, structural, and technical information that describes, situates, and supports the primary data without being the primary data itself.
metadata exposure matters for TPRM because it represents a category of information disclosure that is largely invisible to assessments focused on primary data protection.
- Metadata Exposure Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: HTTP header configuration review , server-identifying headers suppressed; error handling configuration , generic error messages without system detail; document metadata management process , stripping before external distribution.
- Metrics that survive a board meeting
-
A board is accountable for oversight, not for controls: whether the organization understands its exposure, whether the programme is resourced, and whether management is telling the truth. Metrics for a board should serve those three questions. Blocked threats, training completion and a heat map that has not moved in three quarters serve none of them, and a board that nods and moves on is responding fairly to a report that asks for nothing.
the report that produces a decision is the one that shows something moving in a direction that matters and ends with a request. Time to remediate critical findings drifting from nine days to twenty-six prompted a resourcing conversation. The count of customer security commitments with no evidence behind them led directly to funding a compliance resource that a year of heat maps had not achieved.
- MFA Enforcement Gaps
-
MFA enforcement gaps are the authentication paths in an environment where the second factor is not required , paths through which identities can authenticate using only a single factor (typically a password, API key, or certificate) without the additional verification that MFA provides.
MFA enforcement gaps matter for TPRM because vendors who process customer data represent attractive targets precisely because their systems hold data from multiple customers simultaneously.
- MFA Enforcement Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: authentication path inventory , all paths with MFA status; service account authentication method documentation; legacy endpoint inventory with migration or compensating control plan.
- Microsegmentation in Vendor Environments
-
Microsegmentation matters for TPRM because network segmentation confirmation without rule quality assessment may describe topological separation with functional connectivity , segmentation that exists in the network diagram but is traversable through broad zone-level rules.
microsegmentation matters for TPRM because network segmentation confirmation without rule quality assessment may describe topological separation with functional connectivity , segmentation that exists in the network diagram but is traversable through broad zone-level rules.
- Microsegmentation in Vendor Environments: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: segmentation boundary rule description , source, destination, port specificity; default-deny policy on zone boundaries; rule review process and last review date.
- Misconfigured Cloud Storage Exposure via Vendors
-
Cloud object storage , AWS S3, Azure Blob Storage, Google Cloud Storage , is one of the most widely used and most frequently misconfigured services in enterprise cloud environments. It is cheap, scalable, and designed to make data accessible at speed.
cloud storage misconfiguration sits at the intersection of two risk categories that TPRM programs often treat separately: vendor data handling and cloud security.
- Misconfigured Cloud Storage Exposure via Vendors: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: configuration screenshots or exports confirming public access blocks are enabled , not a checkbox on a questionnaire; encryption configuration documentation specifying the encryption standard and key management approach; access logging confirmation with retention period specified.
- Mobile Application CI/CD Security
-
Mobile CI/CD security matters for TPRM because mobile applications distributed through app stores reach users' devices with whatever security configuration the build pipeline produced.
mobile CI/CD security matters for TPRM because mobile applications distributed through app stores reach users' devices with whatever security configuration the build pipeline produced.
- Mobile Application CI/CD Security: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: binary configuration validation in CI/CD pipeline; debug logging verification for release builds; mobile-specific security testing tools used.
- Model Access Control
-
Model access control in the AI security context addresses a challenge that does not exist in traditional software security: a model can be stolen through its API without any breach of the API's access controls. Traditional access controls prevent unauthorised access to a resource.
model access control matters for TPRM because vendors who expose AI model APIs to enterprise customers , and through them, potentially to the enterprise's own customers and partners , create a model extraction attack surface that traditional API security does not address.
- Model Access Control: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: query volume monitoring per API key; model extraction attack assessment results; a vendor who confirms API authentication and rate limiting should be asked about extraction detection. Authentication confirms authorised access. Extraction detection determines whether authorised access is being used to reconstruct the model.
- Model cards
-
A model card is a structured document describing an AI model: what it was trained to do, on what kind of data, how its performance was evaluated and for which populations, its known limitations, and the uses it is and is not intended for. Vendors publish them for models they provide; organizations write them for models they build.
it is the document that answers the questions an AI impact assessment has to ask, and its absence is itself a finding. When a vendor cannot say which populations their model's performance was measured on, you learn that it was measured on one, which is usually the case that mattered: a support triage tool tested in English while a third of your customers write in Spanish.
- Model Drift Risks
-
Model drift is the degradation of a machine learning model's alignment between its production behaviour and its intended behaviour , a misalignment that develops over time as the real-world data distribution that the model encounters in production diverges from the training data distribution the model was built from.
model drift matters for TPRM because the AI models that vendors deploy for consequential decisions , fraud detection, credit scoring, security classification, customer risk assessment , will drift over time in ways that are not always visible in standard performance metrics.
- Model Drift Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: drift-specific monitoring beyond performance metrics; feature importance stability tracking for online learning models; concept drift assessment and retraining cadence.
- Model Theft Risks
-
Model theft risk is the risk that a proprietary AI model's decision logic and capabilities can be reconstructed by an attacker through systematic querying of the model's API , either directly or through a third party with legitimate API access , without the attacker ever accessing the model's weights, architecture, or training data.
model theft matters for TPRM from two directions.
- Model Theft Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: enterprise customer API security requirements; per-key query volume monitoring confirmation; a vendor who confirms API security should be asked about the security of enterprise customer integrations. The vendor's API controls the direct access. The customer integrations are the extended surface through which the model can be accessed indirectly.
- Multi-Cloud CI/CD Security Considerations
-
Multi-cloud CI/CD security matters for TPRM because security architecture inconsistencies across clouds create a single weakest link , the cloud with the weakest credential management or security configuration is the point of highest vulnerability for a pipeline that spans both.
multi-cloud CI/CD security matters for TPRM because security architecture inconsistencies across clouds create a single weakest link , the cloud with the weakest credential management or security configuration is the point of highest vulnerability for a pipeline that spans both.
- Multi-Cloud CI/CD Security Considerations: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: authentication mechanism documentation per cloud; workload Identity implementation status per cloud; service account credential rotation dates.
- Multi-Cloud Vendor Risk
-
Multi-cloud vendor risk is the governance gap that emerges when a vendor's infrastructure spans multiple cloud providers but the customer's due diligence, contractual controls, and ongoing monitoring are scoped to only one , typically the one the customer is aware of or the one the vendor presented during onboarding.
multi-cloud vendor architecture directly challenges one of the foundational assumptions of the standard TPRM assessment model , that the vendor is a single, coherent security environment that can be assessed through a questionnaire and a compliance certification.
- Multi-Cloud Vendor Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: a complete list of cloud providers and regions used in customer data processing , not just the primary platform; SOC 2 scope documentation confirming coverage of all relevant environments , or explicit acknowledgment of what is out of scope and why; a data flow diagram showing how customer data moves through the vendor's multi-cloud architecture.
N
- NAT Security and Network Address Translation Risks
-
NAT security misconceptions matter for TPRM because vendors who describe their internal systems as 'protected by NAT' may be accurately describing the absence of direct IP routability while maintaining port forwarding rules that make those same systems accessible from the internet through deliberate or forgotten path configurations.
NAT security misconceptions matter for TPRM because vendors who describe their internal systems as 'protected by NAT' may be accurately describing the absence of direct IP routability while maintaining port forwarding rules that make those same systems accessible from the internet through deliberate or forgotten path configurations.
- NAT Security and Network Address Translation Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: port forwarding rule inventory and review.
- Nature, timing and extent
-
Nature is what kind of test the auditor performs. Timing is when in the period. Extent is how much, meaning sample size and depth. Together they describe how much work the auditor will do on each control, and all three respond to how much risk the auditor perceives.
understanding these three explains why one request feels trivial and another feels excessive. A control with a strong track record, good evidence and low risk gets light testing. A control in an area with prior exceptions, weak documentation or high exposure gets all three dials turned up.
- Network Access Control in Enterprise Environments
-
NAC matters for TPRM because vendor networks that allow unmanaged devices to join the corporate network have an uncontrolled network access surface , any physical location with a network port or wireless signal becomes a potential network entry point for any device.
NAC matters for TPRM because vendor networks that allow unmanaged devices to join the corporate network have an uncontrolled network access surface , any physical location with a network port or wireless signal becomes a potential network entry point for any device.
- Network Access Control in Enterprise Environments: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: NAC deployment confirmation for wired and wireless; tiered access for managed vs unmanaged devices; a vendor who confirms network security should be asked about NAC. Endpoint security on managed devices protects managed devices. NAC controls what unmanaged devices can access when they connect to the network. Both are required to manage the network access surface.
- Network Access Management for Contractors and Third Parties
-
Contractor network access management matters for TPRM because contractors with corporate network access who have ended their engagement represent the same orphaned access risk as departed employees , but through a lifecycle management gap that HR-integrated identity systems do not automatically address.
contractor network access management matters for TPRM because contractors with corporate network access who have ended their engagement represent the same orphaned access risk as departed employees , but through a lifecycle management gap that HR-integrated identity systems do not automatically address.
- Network Access Management for Contractors and Third Parties: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: contractor offboarding process and SLA records; contract end date integration verification; monthly contractor access audit records.
- Network Access Review and Certification
-
Network access review quality matters for TPRM because access review confirmation without methodology assessment may describe a compliance activity rather than an effective security control.
network access review quality matters for TPRM because access review confirmation without methodology assessment may describe a compliance activity rather than an effective security control.
- Network Access Review and Certification: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: accounts removed per review tracking.
- Network Anomaly Detection and Baseline Deviation
-
Network anomaly detection matters for TPRM because credential theft followed by careful, slow credential abuse is the attack pattern that credential-focused threat actors specifically use to evade signature-based detection.
network anomaly detection matters for TPRM because credential theft followed by careful, slow credential abuse is the attack pattern that credential-focused threat actors specifically use to evade signature-based detection.
- Network Anomaly Detection and Baseline Deviation: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: anomaly detection coverage alongside signatures.
- Network Encryption , What Is and Isn't Encrypted
-
Internal network encryption matters for TPRM because it determines what an attacker who has established an internal foothold can observe.
internal network encryption matters for TPRM because it determines what an attacker who has established an internal foothold can observe.
- Network Penetration Testing in TPRM Context
-
Network penetration testing scope matters for TPRM because pentest report findings describe what was tested, not what exists. A clean external application pentest confirms that the tested external application is reasonably secure.
network penetration testing scope matters for TPRM because pentest report findings describe what was tested, not what exists.
- Network Penetration Testing in TPRM Context: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: internal network scope requirement for critical vendors; scope requirements in critical vendor contracts.
- Network Perimeter vs Identity Perimeter
-
The network-versus-identity perimeter distinction matters for TPRM because vendor network security questionnaire responses that confirm robust firewall and perimeter controls describe a security model that does not address the primary credential-based attack vector.
the network-versus-identity perimeter distinction matters for TPRM because vendor network security questionnaire responses that confirm robust firewall and perimeter controls describe a security model that does not address the primary credential-based attack vector.
- Network Perimeter vs Identity Perimeter: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: MFA enforcement with no bypass pathway confirmation; device management for access control; anomaly detection for credential compromise.
- Network Resilience and Single Points of Failure
-
Network resilience matters for TPRM because vendor platform availability is a direct operational dependency for enterprise customers.
network resilience matters for TPRM because vendor platform availability is a direct operational dependency for enterprise customers.
- Network Resilience and Single Points of Failure: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: ISP and circuit redundancy assessment.
- Network Security Architecture for SaaS-First Environments
-
SaaS-first network security architecture matters for TPRM because using traditional network security assessment frameworks for SaaS-first environments produces assessment results that describe architecture mismatches rather than security gaps.
saaS-first network security architecture matters for TPRM because using traditional network security assessment frameworks for SaaS-first environments produces assessment results that describe architecture mismatches rather than security gaps.
- Network Security Architecture for SaaS-First Environments: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: saaS security posture management review.
- Network Security at the OT/IT Boundary
-
OT/IT boundary security matters for TPRM because vendors who manufacture hardware, operate production facilities, or run logistics systems have OT networks whose security posture directly affects the integrity and availability of their operational processes.
OT/IT boundary security matters for TPRM because vendors who manufacture hardware, operate production facilities, or run logistics systems have OT networks whose security posture directly affects the integrity and availability of their operational processes.
- Network Security for Fast-Growing Vendors , The Scaling Gap
-
Scaling gap security matters for TPRM because rapidly growing vendors may describe security controls at their current quality level while those controls are actually running below the quality level required for their current scale.
scaling gap security matters for TPRM because rapidly growing vendors may describe security controls at their current quality level while those controls are actually running below the quality level required for their current scale.
- Network Security for Fast-Growing Vendors , The Scaling Gap: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: growth trajectory and security investment review.
- Network Security in Third-Party Assessments
-
The questionnaire-technical assessment gap matters for TPRM because it determines the actual assurance value of the network security assessment. For critical vendors, questionnaire-only network security assessment may confirm controls exist while missing the implementation quality issues that create the actual security risk.
the questionnaire-technical assessment gap matters for TPRM because it determines the actual assurance value of the network security assessment.
- Network Security in Third-Party Assessments: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: external firewall rule sample for review; recent external vulnerability scan results; shodan clean external attack surface confirmation.
- Network Security Incident Response , The First 60 Minutes
-
Network security incident response speed matters for TPRM because the dwell time during an active incident , the period between detection and containment , is when the attacker completes their objectives. A vendor with a two-hour deliberation-to-isolation window provides attackers with two hours of active access post-detection.
network security incident response speed matters for TPRM because the dwell time during an active incident , the period between detection and containment , is when the attacker completes their objectives.
- Network Security Metrics That Actually Matter
-
Network security metrics quality matters for TPRM because metrics that describe activity without describing risk cannot support risk-based assessment decisions.
network security metrics quality matters for TPRM because metrics that describe activity without describing risk cannot support risk-based assessment decisions.
- Network Security Metrics That Actually Matter: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: risk-based metric definition and tracking; network threat detection time measurement.
- Network Security Monitoring and SIEM Integration
-
SIEM log coverage matters for TPRM because SIEM presence confirms the monitoring platform exists while log coverage determines what that platform can actually detect.
SIEM log coverage matters for TPRM because SIEM presence confirms the monitoring platform exists while log coverage determines what that platform can actually detect.
- Network Security Monitoring and SIEM Integration: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: critical absent log source identification; a vendor who confirms SIEM should be asked for the log source list. SIEM presence is the platform. Log source breadth is the detection coverage. The ratio of connected to potential log sources reveals what the SIEM can and cannot detect.
- Network Security Requirements in Vendor Contracts
-
Network security contract requirements matter for TPRM because they determine whether the security posture confirmed in assessment is enforceable , whether the enterprise has contractual recourse when the vendor fails to maintain the security controls that the assessment confirmed.
network security contract requirements matter for TPRM because they determine whether the security posture confirmed in assessment is enforceable , whether the enterprise has contractual recourse when the vendor fails to maintain the security controls that the assessment confirmed.
- Network Security Requirements in Vendor Contracts: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: contract security clause specificity review; specific security obligations in critical contracts.
- Network Segmentation Assessment in TPRM
-
Network segmentation assessment matters for TPRM because the security value of a vendor's network segmentation is determined by their most permissive boundary rule, not their most restrictive one.
network segmentation assessment matters for TPRM because the security value of a vendor's network segmentation is determined by their most permissive boundary rule, not their most restrictive one.
- Network Segmentation Assessment in TPRM: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: jump server architecture for production access; most permissive internal boundary rule; segmentation effectiveness testing from internal positions.
- Network Time Protocol Security and Log Integrity
-
NTP security and log timestamp accuracy matter for TPRM because they determine the forensic reliability of a vendor's security logs during incident investigation.
NTP security and log timestamp accuracy matter for TPRM because they determine the forensic reliability of a vendor's security logs during incident investigation.
- Network Topology Documentation and Security Governance
-
Network topology documentation currency matters for TPRM because network security assessments conducted against stale diagrams assess an architecture that does not exist.
network topology documentation currency matters for TPRM because network security assessments conducted against stale diagrams assess an architecture that does not exist.
- Network Visibility and Traffic Analysis
-
East-west traffic visibility matters for TPRM because it determines how quickly a supply chain compromise or internal breach is detected. An attacker who has compromised any system inside a vendor's network will conduct lateral movement to access higher-value targets , source code repositories, build infrastructure, production databases.
east-west traffic visibility matters for TPRM because it determines how quickly a supply chain compromise or internal breach is detected.
- Network Visibility and Traffic Analysis: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: NDR or equivalent internal traffic analysis; network segments with monitoring coverage; a vendor who confirms network monitoring should be asked whether that monitoring includes east-west traffic. Perimeter monitoring detects what enters and exits. East-west monitoring detects what moves inside. Contemporary attacks require both.
- NIST SP 800-161 for Practitioners
-
NIST 800-161 matters for TPRM because it provides a specific, governmentally endorsed framework for assessing software supply chain security that gives practitioners a structured vocabulary for asking questions beyond binary compliance claims.
NIST 800-161 matters for TPRM because it provides a specific, governmentally endorsed framework for assessing software supply chain security that gives practitioners a structured vocabulary for asking questions beyond binary compliance claims.
- NIST SP 800-161 for Practitioners: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: NIST 800-161 implementation tier self-assessment; SR-3 supply chain control documentation; SR-4 provenance tracking implementation evidence.
O
- OAuth Scope Overreach
-
OAuth is an authorization framework that enables applications to obtain limited access to user accounts on third-party services , allowing a user to authorize an application to act on their behalf for specific purposes without sharing their credentials with the application.
OAuth scope overreach matters for TPRM because OAuth authorizations granted to vendor applications persist , often for years , and the scope they provide continues to be available to the vendor application regardless of whether the features that might use that scope are ever built or used.
- OAuth Scope Overreach: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: per-permission justification , each scope tied to a specific feature; minimum necessary scope option , whether reduced scope configurations are available; unused permission identification , permissions currently not exercised by active features.
- Obligation register
-
The list of legal, regulatory and contractual obligations that apply, each in plain words with an owner, the evidence and the deadline.
It is the first artefact in any programme, because scope, controls and retention all depend on knowing what applies.
Taught in DTF-120 · See also: Scope, Evidence
- Open Source as a Third-Party Risk
-
Open-source as third-party risk matters because the most significant supply chain attacks of the past decade have targeted open-source components , Log4Shell, XZ Utils backdoor, event-stream, and similar attacks all exploited the trust that software built on open-source components extends to those components.
open-source as third-party risk matters because the most significant supply chain attacks of the past decade have targeted open-source components , Log4Shell, XZ Utils backdoor, event-stream, and similar attacks all exploited the trust that software built on open-source components extends to those components.
- Open Source as a Third-Party Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: software Bill of Materials for product; SCA tooling and vulnerability monitoring confirmation; remediation SLA for open-source vulnerabilities.
- Open Source License Risk
-
Open-source license risk matters for TPRM because the software your enterprise deploys may impose legal obligations that the enterprise or the vendor has not identified , obligations that can arise after deployment when the legal implications of a license combination are assessed.
open-source license risk matters for TPRM because the software your enterprise deploys may impose legal obligations that the enterprise or the vendor has not identified , obligations that can arise after deployment when the legal implications of a license combination are assessed.
- Open Source License Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SBOM with license information for all components; license scan results identifying copyleft components; legal compliance assessment for AGPL and strong copyleft components.
- Open-Source Supply Chain Risk
-
Open-source supply chain risk is the category of security risk that arises from an application's dependence on software components that are developed, maintained, and distributed outside the organization's control , typically by communities of volunteers, individual developers, or foundations operating under open-source licenses.
open-source supply chain risk is where the third-party risk framework meets the supply chain security framework at their most fundamental intersection.
- Open-Source Supply Chain Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: pre-adoption evaluation process documentation , criteria, approvals, tooling used; malicious package detection capability confirmation , tool name and behavioral analysis capability beyond CVE databases; dependency pinning and lock file confirmation with version control evidence.
- Orphaned Vendor Accounts
-
Orphaned vendor accounts are active user accounts and service accounts in an organization's systems that belong to vendor employees, contractors, or service principals whose operational relationship with the organization has ended.
orphaned vendor accounts matter for TPRM because they represent attack surface that persists after the risk justification for it has ended.
- Orphaned Vendor Accounts: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: vendor account inventory across all systems; offboarding process documentation covering all account types; a vendor who confirms offboarding procedures should be asked to provide a current inventory of all accounts they hold in the customer's environment , not just the primary provisioned access but service accounts and application-specific accounts across all systems. That inventory becomes the offboarding scope. Without it, the offboarding scope is whatever is on the checklist.
- Outsourcing Risk vs Outsourcing Responsibility
-
Outsourcing accountability matters because it defines the enterprise's residual risk from vendor failure.
outsourcing accountability matters because it defines the enterprise's residual risk from vendor failure.
- Outsourcing Risk vs Outsourcing Responsibility: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: professional indemnity and cyber liability insurance details; coverage amounts and exclusions relevant to regulatory liability; regulatory compliance programme for outsourced activities.
- Overprivileged Service Accounts
-
Service accounts are non-human identity principals , accounts created for applications, automation jobs, scheduled processes, monitoring tools, and integration pipelines rather than for individual human users. They authenticate to systems and are granted permissions to perform the functions they are created to support.
overprivileged service accounts matter for TPRM because they represent the most commonly exploited identity category in supply chain attacks.
- Overprivileged Service Accounts: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: service account inventory , count, registry, and ownership documentation; service account access review confirmation , included in formal review cycle with last review date; credential management approach , secrets management platform or static credential policy.
P
- Package Registry Trust Model
-
Package registry trust model matters for TPRM because your vendors' software products are built on packages whose trustworthiness depends not on their past legitimacy but on the current security of their maintainer accounts.
package registry trust model matters for TPRM because your vendors' software products are built on packages whose trustworthiness depends not on their past legitimacy but on the current security of their maintainer accounts.
- Package Registry Trust Model: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: MFA for package publishing accounts; dependency pinning and lock file enforcement; minor version update review process.
- Penetration Testing Integration in CI/CD
-
Penetration testing integration matters for TPRM because annual pentests for vendors with frequent release cadences provide a security baseline at a point in time that may not represent the current security posture.
penetration testing integration matters for TPRM because annual pentests for vendors with frequent release cadences provide a security baseline at a point in time that may not represent the current security posture.
- Penetration Testing Integration in CI/CD: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: pentest date and release count since then; release-triggered testing programme or continuous testing; annual pentest scope documentation , pipeline and infrastructure inclusion.
- Penetration testing scope
-
A penetration test report describes what was tested, how, what was found and what was recommended. The scope section is the one that decides what the rest means. A clean report over a narrow scope says the tester found nothing in the places they were allowed to look, and the places they were not allowed to look are where the next incident will come from.
buyers ask for the report, insurers ask whether testing happens, and the report is read for its findings count rather than for its scope. A report with two low findings over the marketing site is presented as evidence about the product. On the receiving side, a vendor's clean report is accepted without asking whether the API you actually integrate with was in scope.
- Period-end versus period-long controls
-
Controls differ in frequency. Some operate continuously, like authentication. Some operate periodically, like quarterly access reviews. Some operate once a year, like the annual risk assessment or the disaster recovery test. The auditor tests each according to its frequency, and the evidence expectation differs completely between them.
an annual control has exactly one chance to be performed and evidenced within the period. If it is missed, there is no remediation possible inside that period, and the report will record an exception no amount of catch-up can remove.
- Personal data personal information
-
Anything that identifies a living person or can be linked back to one, including identifiers, device data and opinions recorded about someone.
It is broader than most people assume. Data separated from names but still linkable remains personal data.
Taught in PRV-201 · See also: Special category data, Data map
- Personal data and PII
-
PII, personally identifiable information, is a narrower American term for data that identifies a specific person: a name, a social security number, an account number. Personal data under GDPR is broader. It covers anything relating to an identifiable person, whether the identification is direct or indirect, which brings in IP addresses, device identifiers, cookie IDs, location traces and pseudonymised records.
teams scope a privacy programme using the narrow definition, conclude that their logs and analytics contain no PII, and discover later that under the broader definition half their telemetry was personal data all along. The word chosen at the start decides what the programme covers.
- Pipeline-as-Code Security Risks
-
Pipeline-as-code security matters for TPRM because the CI/CD pipeline is the trust bridge between source code and production software.
pipeline-as-code security matters for TPRM because the CI/CD pipeline is the trust bridge between source code and production software.
- Pipeline-as-Code Security Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: CODEOWNERS configuration for pipeline config files; pipeline config change review process; credential access scoping for pipeline jobs.
- Points of focus
-
Under each criterion sits a list of points of focus. They read like requirements. They are not. They are illustrative guidance from the AICPA describing what meeting the criterion might look like in practice, and an organization can meet a criterion without addressing every point of focus, or by addressing some in ways the list never mentions.
teams read the points of focus as a mandatory checklist, build a control for each one, and then maintain those controls for years, producing evidence nobody asked for. Auditors do not test points of focus. They test whether the criterion is met.
- Policy vs Enforcement
-
Policy versus enforcement is the gap between documented security requirements , the standards, procedures, and guidelines that define how security controls should operate , and the technical and operational mechanisms that actually implement those requirements in running systems.
policy versus enforcement matters for TPRM because vendor security assessments that confirm policy existence are confirming the standard the vendor has documented, not the standard their systems enforce.
- Policy vs Enforcement: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: identity platform configuration showing actual enforced password requirements; service account password configuration separately documented; legacy system password configuration inventory.
- Policy, standard, procedure
-
A policy states what must be done and why, at a level that changes rarely and is approved at a senior level. A standard states the specific requirements that implement the policy: the encryption algorithm, the review cadence, the password length. A procedure describes how a named person performs a task, step by step. Three documents, three audiences, three rates of change.
organizations write twenty policies from a template, each mixing all three, and then cannot change a review cadence without a board-level approval cycle, so the cadence stays wrong. Auditors test policies against practice, and a policy carrying a specific requirement the organization does not meet is a finding you wrote for yourself. Staff asked what a policy requires of them cannot say, because it is twelve pages of intent.
- Population and sample
-
The complete set of instances in which a control should have operated during a period, and the subset selected for testing.
A conclusion about a sample only holds if the population was complete, and an export from one system is a list rather than a population.
Taught in AUD-210 · See also: Evidence, IT general controls
- Predecessor auditor considerations
-
When an organization changes service auditors, the new firm considers the prior period's report and opinion when planning its engagement. It may request access to the predecessor's documentation, and it will read the prior report's exceptions and management responses with particular interest.
switching firms is normal and often sensible, for cost, capability or relationship reasons. The transition goes better when the organization can show the prior exceptions were remediated and the reasons for the switch are ordinary. It goes worse when it looks like an escape.
- Privacy by design and by default
-
Privacy by design means data protection is considered throughout the development of a product or process, built into the architecture rather than added afterwards. Privacy by default means that, before a user changes anything, the most protective settings apply: minimum data collected, shortest retention, narrowest sharing. Both are obligations under GDPR Article 25.
by default is the more testable of the two, and the easier to fail. A product can be thoughtfully designed and still ship with sharing on, retention unlimited and a privacy toggle set to off. The defaults are what most users experience, because most users never change them.
- Privacy in product discovery
-
Involving privacy at product discovery means raising data questions when the product is still a sketch: what will be collected, why, from whom, for how long, and whether the same outcome could be achieved with less. At that stage a change is a conversation. At launch the same change is a release, a migration and a delay.
privacy review placed at the end of the process can only approve or block. Blocking a finished product is politically expensive enough that it rarely happens, so late review approves with conditions that are never met. The function becomes a rubber stamp because it was positioned where a stamp was all it could be.
- Privacy metrics
-
Useful privacy metrics measure whether the programme is working rather than how busy it is. Time to respond to rights requests against the statutory deadline. The proportion of processing activities with a documented lawful basis. How recently the record of processing was updated. The number of designs changed at privacy review. The proportion of vendors with a compliant DPA. Each answers a question about effectiveness.
boards ask whether the programme is working, and the answer offered is usually a count: requests received, assessments completed, training sessions delivered. Volume rises with awareness and with the size of the business, which makes a good year look like a bad one and tells the board nothing about risk.
- Privacy notices
-
GDPR Articles 13 and 14 prescribe what must be told to data subjects when their data is collected: the controller's identity, the purposes and lawful basis, the recipients, any transfers, the retention period, their rights, and where the data came from if not from them. The information must be provided in a concise, transparent, intelligible and easily accessible form, using clear and plain language.
notices are frequently complete and unreadable. Every required element is present, buried in four thousand words of legal drafting that no data subject will read. That fails the transparency requirement even though it passes the completeness one, because information that cannot be understood has not been provided.
- Privacy operations tooling
-
Privacy operations tooling handles the recurring work of a programme: intake and tracking of rights requests with deadlines, maintenance of the record of processing, consent recording and preference management, DPIA workflows, vendor assessments, and evidence of all of it. It is what turns a set of obligations into a set of routines.
privacy work is repetitive, deadline-bound and evidence-heavy, which is exactly the shape that fails when handled by memory and email. A rights request tracked in a shared inbox misses its deadline. A RoPA in a spreadsheet drifts. A consent record in a boolean column proves nothing.
- Privileged access management
-
Privileged access is the ability to change systems, data or other people's access: administrator roles, database write access, deployment rights, break-glass accounts. Managing it means knowing who holds it, granting it for a purpose and a period rather than permanently, separating it from the accounts people use every day, and recording what was done with it.
standing privileged access is the finding that appears in nearly every first assessment, it is the first thing a SOX auditor looks for on the systems that produce the numbers, and it is the reason a phished engineer's credentials become a breach rather than an incident. It is also the finding that takes longest to unwind, because removing it changes how people work.
- Privileged Access Management (PAM) Gaps
-
Privileged access management is a set of tools and processes designed to control, monitor, and audit the use of privileged credentials , accounts with elevated access to systems, data, and infrastructure.
PAM gaps matter for TPRM because managed services and infrastructure vendors who hold privileged access to customer environments represent some of the most consequential supply chain risk points in the enterprise landscape.
- Privileged Access Management (PAM) Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: customer environment credential storage confirmation , enterprise PAM vault; session recording confirmation for customer access with retention period; PAM coverage scope documentation , internal and external access.
- Privileged Access Management (PAM) in Vendor Context (DoNotBeLarry Insights)
-
Privileged Access Management (PAM) is not just about securing admin credentials, it is about controlling the conditions under which high-impact actions can occur across an environment. At its core, PAM governs access to systems, data, and capabilities that can materially change the state of the enterprise.
in third-party environments, privileged access is rarely scoped as tightly as it should be.
- Privileged Network Access Management
-
Privileged network access management matters for TPRM because network administrators have the access to modify the security controls that protect all other systems.
privileged network access management matters for TPRM because network administrators have the access to modify the security controls that protect all other systems.
- Privileged Network Access Management: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: session recording implementation on privileged access infrastructure; a vendor who confirms bastion host architecture for privileged access should be asked about session recording and SSH forwarding. Bastion presence is the chokepoint. Session recording and logging bypass prevention are the observability controls that make the chokepoint useful for security purposes.
- Processor terms Article 28, DPA
-
The mandatory contractual terms between a controller and a processor: documented instructions, confidentiality, security, sub-processors, rights support, deletion and audit.
The clauses are specific enough to check against, and a missing one is a finding a regulator can write in a sentence.
Taught in PRV-203 · See also: Business associate agreement, Transfer mechanism
- Programming Language Runtime Security
-
Runtime security matters for TPRM because a vendor who delivers well-patched application code running on an EOL runtime is delivering software whose foundational execution environment has permanent unpatched vulnerabilities.
runtime security matters for TPRM because a vendor who delivers well-patched application code running on an EOL runtime is delivering software whose foundational execution environment has permanent unpatched vulnerabilities.
- Programming Language Runtime Security: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: migration timeline for EOL or near-EOL runtimes; a vendor who confirms application dependency currency should be asked about runtime currency. Application SCA covers the dependencies. Runtime assessment covers the layer the dependencies run on. Both are required for complete supply chain health assessment.
- Prompt injection
-
Prompt injection is an attack on a system built on a language model, where content the model reads, such as a document, a web page, an email or a user's message, contains text that the model treats as instructions rather than as data. The model then does what the attacker's text says: exfiltrates information it was given, ignores its rules, or takes an action through a tool it has access to.
it is the vulnerability specific to this class of system, and it does not have a patch. A model cannot reliably distinguish instructions from data in the same channel, so any system that lets a model read untrusted content and then act on it carries the exposure by design. The risk scales with what the model can do: a model that can only answer is embarrassing when injected; one that can send email or change records is dangerous.
- Prompt Injection via Vendors
-
Prompt injection is an attack technique that exploits the inability of LLMs to reliably distinguish between legitimate operator instructions , typically delivered through a system prompt , and attacker-controlled instructions embedded in user input or in data the LLM processes. The LLM is designed to follow instructions.
prompt injection via vendors matters for TPRM because every AI product deployed by a vendor that has access to enterprise data is a potential prompt injection attack surface.
- Prompt Injection via Vendors: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: prompt injection testing methodology and results; agentic tool access scope documentation; architectural controls , LLM gateway, guardrails.
- Protected health information PHI
-
Individually identifiable health information held or transmitted by a covered entity or a business associate.
It turns up where nobody designed for it: support tickets, application logs, error tracking and test environments loaded from production.
Taught in PRV-203 · See also: Business associate agreement, Personal data
- Pseudonymisation and anonymisation
-
Pseudonymisation replaces identifying fields with a token or key, such that the data cannot be attributed to a person without additional information held separately. The data remains personal data under GDPR, because re-identification is possible. Anonymisation renders the data such that a person cannot be identified by any means reasonably likely to be used, and anonymous data falls outside GDPR entirely.
almost nothing marketed as anonymised actually meets the test. Removing names and leaving dates of birth, postcodes and job titles produces data that can be re-identified with modest effort. The standard is whether re-identification is reasonably likely, taking into account the cost, the time, the technology and the other data available.
- Purpose limitation
-
Purpose limitation requires that personal data be collected for specified, explicit and legitimate purposes and not further processed in a manner incompatible with those purposes. Data collected to deliver a service cannot drift into serving a different purpose without either a compatibility assessment or a fresh lawful basis for the new use.
the defining example is support data becoming training data. Customer conversations collected to resolve issues are later used to train a model, improve a product, or build a sales signal. Nobody decided to repurpose the data; it was simply there and useful. Purpose limitation is the principle that says usefulness is not a basis.
Q
- Qualified opinions
-
The auditor's opinion comes in four forms. Unqualified means the controls were suitably designed and operated effectively. Qualified means they were, except for a specific matter the auditor describes. Adverse means they were not. A disclaimer means the auditor could not form an opinion at all. The opinion is on the first page, in language designed to be unremarkable.
the opinion is the single most important sentence in the report, and it is routinely skipped in favour of the testing tables. A qualified opinion is not a failed audit, but it is the auditor telling you that something material did not hold, and the paragraph explaining what deserves to be read before anything else.
- Quantified risk FAIR-style analysis
-
A risk expressed as a range of loss over a period, built from stated frequency and magnitude estimates.
Ordinal scales cannot be compared against the cost of a control. A range with stated confidence can.
Taught in RSK-210 · See also: Risk appetite, Risk treatment
- Questionnaire Fatigue vs Real Risk
-
Questionnaire fatigue matters for TPRM because it represents the dominant approach to third-party risk assessment and it systematically underperforms on the question that risk management most needs answered: what are the specific risks created by this specific vendor relationship, and are those risks adequately controlled?
questionnaire fatigue matters for TPRM because it represents the dominant approach to third-party risk assessment and it systematically underperforms on the question that risk management most needs answered: what are the specific risks created by this specific vendor relationship, and are those risks adequately controlled?
- Questionnaire Fatigue vs Real Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: answers to relationship-specific questions with supporting evidence; acknowledgement of the specific risk profile the relationship creates; evidence of controls addressing the specific identified risks.
R
- Readiness assessments
-
A readiness assessment is a walkthrough of the intended scope, controls and evidence before the observation period begins, usually performed by the auditor or a consultant. It identifies gaps while they are still cheap to fix and before they become exceptions in a report your customers will read.
an exception found in readiness is a task. The same gap found in the audit is a finding, permanently recorded, in a document that will be read by every prospect for the next year. The economics are not close.
- Record of processing activities RoPA, Article 30 record
-
The register of what personal data an organization processes, for what purposes, with whom it is shared, for how long and under what safeguards.
A regulator can ask for it by name and expect it immediately. Built by survey it is wrong on the day it is finished; built from systems it survives.
Taught in PRV-220 · See also: Data map, Data protection impact assessment
- Records of processing activities
-
The record of processing activities, required by GDPR Article 30, is an inventory of every processing activity a controller or processor carries out: the purposes, the categories of data and of data subjects, the recipients, any international transfers, the retention periods, and a description of security measures. It is the map of what the organization does with personal data.
it is the first thing a supervisory authority asks for, because it reveals in one document whether a programme exists at all. Nobody maintains a RoPA by accident. Its presence, completeness and currency say more about the organization's data governance than any policy does.
- Recovery objectives
-
The recovery time objective is how long a service may be down before the loss becomes unacceptable. The recovery point objective is how much data, measured in time, you can afford to lose: the gap between the last good copy and the failure. They are separate promises. A four-hour RTO with a twenty-four-hour RPO means you will be back by lunch having lost yesterday.
customers ask for both in security schedules, insurers ask for them on applications, and continuity frameworks require them per service. They also come up the day a restore is needed, when the organization discovers that the RPO written in the policy assumed nightly backups that were switched to weekly during a cost review.
- Regulatory Blind Spots
-
Regulatory blind spots are the regulatory frameworks that apply to a vendor relationship , determined by data location, data subject residency, industry vertical, or operational geography , that are not assessed because the assessment programme was designed around a different regulatory context.
regulatory blind spots matter for TPRM because unassessed regulatory frameworks create unmanaged compliance exposure.
- Regulatory Blind Spots: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: infrastructure geography , specific cloud regions where data is stored; data subject residency confirmation , which jurisdictions' residents are in scope; DPA execution confirmation for GDPR-applicable relationships.
- Regulatory Interpretation Gaps
-
Regulatory interpretation gaps are divergences between how different parties , regulators, organizations, vendors, and legal advisors , interpret the specific requirements of applicable regulations.
regulatory interpretation gaps matter for TPRM because the customer's regulatory obligation is satisfied by the vendor implementing the requirement according to the interpretation the regulator will use , not according to the interpretation the vendor finds most operationally convenient or legally defensible.
- Regulatory Interpretation Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: specific retention period calculation , start event, end event, exceptions; confirmation that calculation matches customer's interpretation; regulatory basis for the vendor's interpretation.
- Regulatory Mapping in TPRM
-
Regulatory mapping matters because compliance gaps discovered during a regulatory examination are significantly more costly than gaps identified and remediated through proactive programme management. A DORA ICT concentration risk assessment gap identified in a gap analysis in 2023 can be remediated before the 2025 application date.
regulatory mapping matters because compliance gaps discovered during a regulatory examination are significantly more costly than gaps identified and remediated through proactive programme management.
- Regulatory Mapping in TPRM: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: regulatory framework list applicable to TPRM; DORA gap analysis (where applicable); a vendor who confirms a mature TPRM programme should be asked which regulations it is designed to satisfy and whether those regulations are current. Programme maturity for 2020's requirements is not programme maturity for 2024's.
- Regulatory Overlap Confusion
-
Regulatory overlap occurs when multiple regulatory frameworks apply to the same organization, the same data, or the same systems , each imposing requirements that may be complementary, equivalent, or conflicting. HIPAA and PCI-DSS are the most common healthcare data processing overlap.
regulatory overlap confusion matters for TPRM because vendors operating in overlapping regulatory contexts may have compliance gaps in the intersection , areas where their HIPAA programme does not satisfy PCI-DSS requirements and their PCI-DSS programme does not address HIPAA specifics, leaving the overlap unaddressed.
- Regulatory Overlap Confusion: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: regulatory overlap systems mapping , systems subject to multiple frameworks identified; more-stringent requirement analysis for key overlap areas; unified compliance assessment for overlap systems.
- Release Approval Workflows
-
Release approval workflows matter for TPRM because automatic production deployments without human approval checkpoints mean that security findings that are not configured as hard blockers will deploy to production on every merge.
release approval workflows matter for TPRM because automatic production deployments without human approval checkpoints mean that security findings that are not configured as hard blockers will deploy to production on every merge.
- Release Approval Workflows: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: production environment protection configuration with required reviewers; advisory finding acceptance process for production deployment; security finding status requirement in release review.
- Remote Access Security for Hybrid Workforces
-
Remote access endpoint security matters for TPRM because the BYOD workforce creates a scenario where corporate network access is occurring from devices with no required security baseline.
remote access endpoint security matters for TPRM because the BYOD workforce creates a scenario where corporate network access is occurring from devices with no required security baseline.
- Remote Access Security for Hybrid Workforces: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: device posture check implementation for VPN access; managed device requirements for sensitive systems; MDM and endpoint security agent requirements.
- Report distribution and NDA
-
A SOC 2 Type II report is a restricted-use document, intended for the audited company, its customers and their auditors, and people with sufficient understanding of the system to interpret it. It is not meant for general publication. The SOC 3 exists for that purpose.
the report contains detail about your controls, your system and the exceptions found, which is exactly what an attacker would like to read. It also carries the auditor's name and opinion, which the auditor does not want interpreted by people without the context to do so.
- Reporting vs Insight
-
Reporting is the communication of programme metrics and activities , counts, averages, completion rates, and status updates that describe what the programme has done.
reporting versus insight matters for TPRM because the programme's governance value is determined by the quality of decisions it enables, not by the volume of its outputs.
- Reporting vs Insight: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: honest assessment of how vendor risk profile has changed in the last twelve months; significant open risks in the vendor's security programme; improvements made in the last twelve months.
- Reproducible Builds in Practice
-
Reproducible builds matter for TPRM because they are the technical prerequisite for independent verification of software provenance at the binary level.
reproducible builds matter for TPRM because they are the technical prerequisite for independent verification of software provenance at the binary level.
- Reproducible Builds in Practice: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: source code commit reference for distributed artifacts; reproducible Builds project participation or equivalent; a vendor who confirms supply chain security should be asked about reproducibility. Reproducibility is the technical foundation for independent verification. Without it, binary provenance must be accepted on distribution infrastructure trust alone.
- Retention schedule
-
The record of how long each category of data is kept, why, what triggers deletion and where every copy lives.
A schedule nobody executes is a written commitment you are visibly failing to meet. The hard part is the copies, not the primary system.
Taught in PRV-270 · See also: Legal hold, Data map
- Retention schedules
-
A retention schedule sets how long each category of personal data is kept, and why. Each period is tied to a specific legal, regulatory, contractual or operational reason. When the reason expires, so does the retention, and the data is deleted or anonymised. The schedule is the operational expression of the storage limitation principle.
seven years is applied to everything because it sounds defensible. It is defensible for financial records in many jurisdictions and for almost nothing else. Marketing data, support tickets, application logs and applicant records each have their own justified period, and it is usually far shorter.
- Retrieval and data leakage
-
Retrieval-augmented systems answer questions by searching an index of documents and passing the relevant ones to a model. The model can therefore surface anything in the index, and the index frequently contains material that the person asking was never entitled to see. The model has no idea; it was given the document and asked to summarise.
it is the most common way an internal assistant becomes a data breach. A helpful index built over a shared drive, a ticketing system and a wiki includes the HR folder somebody shared too widely, the salary spreadsheet, the export of customer records a support engineer made two years ago. The assistant answers a question about one of them politely and accurately to someone who should not have asked.
- Right to audit
-
A right to audit clause gives you the contractual ability to examine a vendor's controls, either directly, through a third party, or by receiving their independent assurance reports. Most organizations never exercise the on-site version. What they use, every year, is the clause that says the vendor will provide its assurance report on request.
it is one of the six contract clauses that carry third-party risk, and it is the one people negotiate hardest for while planning never to use it. Its real value is twofold: it gives you the assurance report without an argument, and it changes the vendor's behaviour by existing. Regulated customers also need it for their supervisors, which makes it non-negotiable in those deals.
- Right-sized control sets
-
A control set should cover the criteria with the smallest number of controls the organization can genuinely operate and evidence every period. Every control in the set is a recurring obligation: it must run, on schedule, and leave a record, for as long as it remains in the set.
large control sets look rigorous and fail in practice. A set of two hundred controls, adopted wholesale from a framework, contains dozens nobody actually operates, and each of those becomes an exception at the first audit that samples it. The organization has created its own findings.
- Right-to-Audit Clauses in Practice
-
Right-to-audit matters because it is the mechanism through which the enterprise can obtain direct, independent verification of vendor security controls that cannot be obtained through questionnaires and document review. A vendor questionnaire response describes what the vendor says their controls are.
right-to-audit matters because it is the mechanism through which the enterprise can obtain direct, independent verification of vendor security controls that cannot be obtained through questionnaires and document review.
- Right-to-Audit Clauses in Practice: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: audit clause scope and limitation confirmation; substitution clause specifics , what can be substituted and for what purpose; notice period and logistics process.
- Risk acceptance
-
A decision by someone with the authority to make it that a known risk will not be treated further for now.
It is a treatment with a date on it. Without an expiry it becomes a risk nobody is looking at, accepted by someone who may have left.
Taught in RSK-220 · See also: Risk treatment, Risk appetite
- Risk Acceptance Governance
-
Risk acceptance governance matters because accepted risks are risks the organization has consciously chosen to carry. If that choice is made without adequate compensating controls, monitoring, or time bounds, the organization is simply deferring the risk materialisation rather than managing it.
risk acceptance governance matters because accepted risks are risks the organization has consciously chosen to carry.
- Risk Acceptance Governance: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: risk acceptance policy with time bounds and authorisation levels; active accepted risk register with review dates; compensating controls for material accepted risks.
- Risk Acceptance Misuse
-
Risk acceptance is a governance mechanism for formally acknowledging that a specific risk or control gap will not be remediated within the standard remediation timeframe, and documenting the business rationale for that decision, the residual risk level, the business owner who accepts accountability, and the conditions under which the acce
risk acceptance misuse matters for TPRM because it produces risk registers that appear comprehensive , all identified risks are documented and managed , while in practice containing a growing population of aged acceptances that represent genuine unmitigated risks being carried without active oversight.
- Risk Acceptance Misuse: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: risk register filtered to aged acceptances with dates and review history; remediation commitment tracking for acceptances with planned remediation; GRC platform acceptance expiry configuration.
- Risk appetite
-
A statement of how much risk an organization is willing to carry, expressed so that exceeding it is observable.
Two tests decide whether it means anything: could we exceed it, and would we know.
Taught in RSK-230 · See also: Risk treatment, Quantified risk
- Risk Appetite Misalignment
-
Risk appetite misalignment in vendor management is the gap between the organization's formally defined tolerance for vendor-related risk , expressed in terms of concentration limits, security minimums, data volume thresholds, and integration depth criteria , and the actual risk profile of the existing vendor portfolio.
risk appetite misalignment matters for TPRM because risk appetite frameworks are governance commitments , the board has defined the level of vendor concentration and security risk it is willing to accept.
- Risk Appetite Misalignment: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: data processing component breakdown , what is processed where; technical feasibility assessment for processing scope reduction; transition timeline and cost estimates for concentration reduction.
- Risk assessment under CC3
-
CC3 requires the organization to specify its objectives, identify the risks to achieving them, analyse those risks including fraud risk, and reassess when significant changes occur. In practice, it requires a documented risk assessment that is genuinely maintained rather than produced once for the audit.
CC3 is the criterion that connects everything else. Controls exist because risks were identified, and without a record of that reasoning the control set looks arbitrary. It is also where auditors look for evidence that the organization thinks about its own exposure rather than simply operating a checklist.
- Risk Communication Gaps
-
Risk communication is the process of ensuring that identified risks reach the people who have the authority, resources, or operational responsibility to act on them , not just the people who have the technical responsibility to track them.
risk communication gaps matter for TPRM because the programme's value to the organization is determined by the quality of decisions it enables , and decisions require communication that reaches decision-makers in formats that support informed action.
- Risk Communication Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: audience matrix for risk communication; business owner notification records for high-priority findings; communication format documentation for different audiences.
- Risk Prioritisation Failures
-
Risk prioritisation is the process of ordering risks by the urgency and intensity of management response based on their actual consequence , the combination of likelihood and impact that determines which risks, if unmitigated, would cause the greatest harm.
risk prioritisation failures matter for TPRM because they determine where remediation resources and management attention are focused , and consequently where risk reduction actually occurs.
- Risk Prioritisation Failures: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: within-tier risk ranking methodology or criteria; remediation timelines differentiated by consequence; most consequential open findings and their remediation status.
- Risk Quantification Challenges
-
Risk quantification is the practice of expressing risk in terms of probability and magnitude , the likelihood that a specific adverse event will occur and the financial or operational impact if it does.
risk quantification challenges matter for TPRM because the governance and business decisions that depend on vendor risk assessments , budget allocation, insurance, risk transfer, board reporting, and remediation prioritisation , increasingly require financial risk expressions rather than ordinal rankings.
- Risk Quantification Challenges: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: data volume and classification for customer data processed; breach notification and response cost estimates; cyber insurance coverage limits and relevant exclusions.
- Risk Register Accuracy
-
A risk register is the authoritative inventory of identified risks that are currently being managed , the active risk landscape that governance processes use to prioritise remediation, allocate resources, and report to leadership.
risk register accuracy matters for TPRM because the register is the primary tool for governance decision-making , prioritising remediation resources, monitoring high-risk items, and reporting current risk to leadership.
- Risk Register Accuracy: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: evidence of completed remediation steps for long-duration findings; remaining remediation steps with target completion dates; root cause for delay if remediation is behind schedule.
- Risk Scoring Subjectivity
-
Risk scoring subjectivity is the variation in assessment outcomes that results from differences in assessor interpretation of evidence, compensating controls, and scoring criteria within a defined risk assessment methodology. It is not a failure of the methodology's structure , the structure may be completely consistent and well-defined.
risk scoring subjectivity matters for TPRM because risk scores drive consequential decisions , vendor approval or rejection, required risk mitigation measures, monitoring intensity, and contractual requirements.
- Risk Scoring Subjectivity: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: technical evidence of compensating control implementation; specific explanation of how the compensating control reduces the missing control's risk; any independent validation of compensating control effectiveness.
- Risk treatment
-
The decision taken about an assessed risk: modify, share, avoid or accept, with the controls that deliver it.
Controls should be derived from treatment decisions. A control set chosen from a template cannot explain why any control is there.
Taught in RSK-201 · See also: Risk acceptance, Statement of Applicability
- Role-Based Access vs Actual Usage
-
Role-based access vs actual usage matters for TPRM because vendors who use RBAC for their employee access management may have a population of users with significantly broader access than their actual work requires , and that excess access represents a credential compromise blast radius that is larger than the functional need.
role-based access vs actual usage matters for TPRM because vendors who use RBAC for their employee access management may have a population of users with significantly broader access than their actual work requires , and that excess access represents a credential compromise blast radius that is larger than the functional need.
- Role-Based Access vs Actual Usage: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: permission utilization data , used vs unused permissions for relevant roles; usage analytics integration in access review process; role recalibration history , when roles were last updated based on usage patterns.
- Runtime Application Self-Protection in CI/CD Context
-
RASP matters for TPRM because it represents the security layer between the network perimeter controls a vendor has confirmed and the application's actual runtime behaviour.
RASP matters for TPRM because it represents the security layer between the network perimeter controls a vendor has confirmed and the application's actual runtime behaviour.
- Runtime Application Self-Protection in CI/CD Context: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: RASP or runtime protection deployment confirmation; runtime protection coverage and detection capability; CI/CD integration for runtime protection deployment.
S
- SaaS Security Posture vs Traditional Vendor Assessment
-
SaaS security posture matters because the most common attack vector against SaaS platforms is not platform-level compromise , it is credential-based access through compromised user accounts, overprivileged service accounts, and persistent API tokens.
saaS security posture matters because the most common attack vector against SaaS platforms is not platform-level compromise , it is credential-based access through compromised user accounts, overprivileged service accounts, and persistent API tokens.
- SaaS Security Posture vs Traditional Vendor Assessment: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: API access for SSPM integration confirmation; user and permission reporting capabilities; API credential rotation feature support.
- Sale and sharing
-
Disclosing personal information for money or other value (sale), or so that advertising can follow a person across sites (sharing or targeted advertising).
Most organizations that say they do not sell data are sharing it through advertising tags, which is where unexpected scope comes from.
Taught in PRV-202 · See also: Global Privacy Control, Consent management platform
- Sale and sharing under CPRA
-
California's CPRA defines sale as disclosing personal information to a third party for monetary or other valuable consideration, and sharing as disclosing it to a third party for cross-context behavioural advertising, whether or not anything of value changes hands. Both trigger the consumer's right to opt out and the obligation to honour it.
advertising pixels caught most companies by surprise. A tracking pixel that sends browsing data to an advertising platform in exchange for measurement or audience building is a sale or a share under this definition, even though no invoice exists. The consideration is the service received, and the opt-out obligation applies.
- Sampling and populations
-
Auditors do not test every instance of a control. They sample, and the sample size follows the control's frequency and the size of the population. A daily control might be sampled at 25 instances across the year; a quarterly one at two; a control that runs once at one. The approach is standard and the sizes are conventional.
the population comes first, and producing it is usually your job. The auditor needs a complete and accurate list of every instance the control ran, every change, every new starter, every access review, before selecting from it. A population generated from a filtered report, or a system that does not capture every instance, gives the auditor a sample of a subset, and the conclusion drawn from it is unsupported.
- SAST , What It Catches and What It Doesn't
-
SAST gaps matter for TPRM because SAST confirmation without coverage and remediation assessment provides assurance for the tool's presence rather than the tool's effectiveness.
SAST gaps matter for TPRM because SAST confirmation without coverage and remediation assessment provides assurance for the tool's presence rather than the tool's effectiveness.
- SAST , What It Catches and What It Doesn't: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SAST coverage map with excluded modules and rationale; SAST remediation SLA by severity; a vendor who confirms SAST should be asked for coverage and remediation backlog. SAST presence is the tool. Coverage and remediation velocity are the effectiveness metrics.
- SAST vs Actual Risk Reduction
-
SAST is one of the most commonly cited application security practices in vendor questionnaire responses, and one of the most commonly misrepresented , not through deliberate deception, but because the question 'do you use SAST' can be answered accurately by any vendor whose development toolchain includes a scanner, regardless of whether t
SAST is one of the most commonly cited application security practices in vendor questionnaire responses, and one of the most commonly misrepresented , not through deliberate deception, but because the question 'do you use SAST' can be answered accurately by any vendor whose development toolchain includes a scanner, regardless of whether t
- SAST vs Actual Risk Reduction: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: open critical and high finding counts for the specific application, with trend data showing direction of change; average time-to-remediation for critical findings , a number, not a policy statement; blocking policy confirmation with exception process documentation.
- Scope
-
The decision about which entities, systems, products, environments and data a programme or certification covers, and what is excluded and why.
It is the single largest lever over cost, and it is a decision rather than a discovery. Unbounded scope is how ninety days becomes eighteen months.
Taught in AUD-250 · See also: Obligation register, Statement of Applicability
- Scope and system boundary
-
The system boundary defines which systems, people, processes and data are inside the audit and which are not. Everything inside is described and tested. Everything outside is untested, and the report says nothing about it. The audited company draws the boundary.
a narrow boundary produces a cheaper, faster audit and a report that covers less than a reader assumes. A broad boundary produces the opposite. Neither is wrong, but the choice should be made deliberately, and the boundary should match what customers actually buy.
- Scope creep between audit cycles
-
Products change faster than audit scope. Between one report and the next, a vendor may launch new services, open new regions, acquire a company or migrate infrastructure. The report you hold describes the system as it was during a period that ended some time ago.
the report is accurate, and simultaneously does not cover the thing you are buying now. A customer who adopted a new feature six months ago may be relying on a report whose system description predates that feature's existence.
- Secrets & Key Management
-
Secrets management is the discipline of controlling how sensitive credentials , API keys, passwords, certificates, encryption keys, tokens, and connection strings , are created, stored, distributed, used, and retired. It sounds like a straightforward IT hygiene problem, and that is exactly why it is so consistently underestimated.
vendor integrations run almost entirely on secrets.
- Secrets & Key Management: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: named secrets management platform with documented access controls and audit logging; rotation policy with a defined maximum credential lifetime , ideally 90 days or less; process for immediate revocation when personnel with access depart.
- Secrets in Source Code
-
Secrets in source code matter for TPRM because your vendors' development repositories may contain credentials that provide access to systems that process your data , production database credentials, cloud provider keys, API tokens for services that handle your data.
secrets in source code matter for TPRM because your vendors' development repositories may contain credentials that provide access to systems that process your data , production database credentials, cloud provider keys, API tokens for services that handle your data.
- Secrets in Source Code: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: pre-commit secret detection hook implementation; credential rotation confirmation for any historical exposures; secret management policy and enforcement.
- Secrets Management in CI/CD
-
Secrets management hygiene matters for TPRM because CI/CD pipeline credentials , cloud provider access keys, artifact registry tokens, production deployment credentials , are among the highest-value credentials in an enterprise's environment.
secrets management hygiene matters for TPRM because CI/CD pipeline credentials , cloud provider access keys, artifact registry tokens, production deployment credentials , are among the highest-value credentials in an enterprise's environment.
- Secrets Management in CI/CD: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: secret rotation schedule and last rotation dates; secret scope documentation , which steps access which secrets; a vendor who confirms secrets management should be asked about rotation, masking, and git history hygiene. Secrets management is the storage mechanism. Rotation, masking, and history hygiene determine whether the stored secrets remain secret.
- Secure Coding Standards Enforcement
-
A secure coding standard is a defined set of rules, guidelines, and requirements that specify how developers should write code to avoid introducing security vulnerabilities.
secure coding standards are the upstream control that determines the security quality of code before automated scanning tools get a chance to catch what the standards were designed to prevent.
- Secure Coding Standards Enforcement: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SAST rule mapping documentation showing which standard requirements are automatically enforced through tooling; training platform confirmation with language-specific, standard-relevant content description; compliance metrics , percentage of codebase meeting standard requirements through measurable tooling.
- Secure SDLC in Vendor Environments
-
Vendor application security is the risk category most directly connected to what your organization actually experiences when a vendor's software is breached, exploited, or found to contain vulnerabilities. Every other dimension of vendor security , cloud configuration, access management, encryption , operates at the infrastructure layer.
vendor application security is the risk category most directly connected to what your organization actually experiences when a vendor's software is breached, exploited, or found to contain vulnerabilities.
- Secure SDLC in Vendor Environments: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: penetration test executive summary scoped to the specific application, dated within the last 12 months, with open finding counts by severity; SAST tool confirmation with scan frequency, codebase coverage, and remediation SLA documentation; vulnerability disclosure process documentation with committed notification timeline and remediation SLA by severity.
- Security Champions Programme in DevSecOps
-
Security champions programmes matter for TPRM because they represent the organizational mechanism that distributes security into the development workflow where it can most effectively prevent vulnerabilities before they are committed.
security champions programmes matter for TPRM because they represent the organizational mechanism that distributes security into the development workflow where it can most effectively prevent vulnerabilities before they are committed.
- Security Champions Programme in DevSecOps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: active champion count by development team; last champion training or meeting date; champion-attributed security findings last quarter.
- Security Debt Tracking and Remediation Velocity
-
Security debt tracking matters for TPRM because the ratio of findings generated to findings remediated is the most accurate available indicator of whether a DevSecOps programme is actually improving security posture.
security debt tracking matters for TPRM because the ratio of findings generated to findings remediated is the most accurate available indicator of whether a DevSecOps programme is actually improving security posture.
- Security Debt Tracking and Remediation Velocity: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: current finding backlog by severity; net backlog change last quarter , growth or reduction; critical and high finding aging distribution.
- Security Gate Bypasses in CI/CD
-
Security gate bypasses matter for TPRM because they represent the difference between security gates as controls and security gates as monitoring. A gate that can be bypassed unilaterally by administrators on demand is a monitoring tool that generates alerts when the alert is inconvenient.
security gate bypasses matter for TPRM because they represent the difference between security gates as controls and security gates as monitoring.
- Security Gate Bypasses in CI/CD: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: bypass governance policy , who can bypass and with what approval; bypass event audit log availability; bypass log review process and frequency.
- Security Operations Silos
-
Security operations silos are the organizational and technical separations between domain-specific security teams , application security, cloud security, endpoint security, SOC, network security , that prevent cross-domain visibility, cross-domain finding correlation, and cross-domain attack chain identification.
security operations silos matter for TPRM because the attack chains that sophisticated supply chain attackers use to reach customer data typically span multiple security domains , exploiting application vulnerabilities to gain initial access, endpoint misconfigurations to escalate privilege, and cloud misconfigurations to reach sensitive
- Security Operations Silos: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: cross-domain correlation mechanism , tool or process; red team exercise scope , cross-domain chains tested; multi-domain attack path assessment capability.
- Security questionnaires at scale
-
Answering buyer security questionnaires is a recurring cost of selling to regulated organizations, and the default handling is bad in a specific way: each one is answered from memory by whoever answered the last one, slightly differently each time, and nobody records what was said. Six months later a similar questionnaire arrives and the work starts from nothing.
three questionnaires in a quarter asking about encryption at rest get three different answers, none wrong, each emphasising something different. A fourth, answered in a hurry, commits to a control the company does not operate, and that answer is now a contractual representation nobody in engineering knows was made.
- Security Testing in Feature Flags
-
Feature flag security matters for TPRM because feature flags represent a deployment mechanism that bypasses the CI/CD pipeline controls if the flag enable process does not have equivalent security governance.
feature flag security matters for TPRM because feature flags represent a deployment mechanism that bypasses the CI/CD pipeline controls if the flag enable process does not have equivalent security governance.
- Security Testing in Feature Flags: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: feature flag access control documentation , who can enable in production; approval workflow for new feature flag enables; security review linkage to feature flag state.
- Segregation of duties
-
Segregation of duties is the principle that no single person can complete a sensitive action end to end: the one who requests does not approve, the one who develops does not deploy to production, the one who grants access does not review it, the one who changes a payee does not release the payment. It is a control against both error and fraud, and it is the control small organizations find hardest to operate.
auditors test it directly, financial controls depend on it, and its absence is how one compromised or careless person becomes a material event. It also comes up in access reviews, where the reviewer who approves their own access has told the auditor something, and in change control, where a developer who can merge and deploy alone has removed the review from the process.
- Selecting the Right Network Security Assessment Methodology
-
Assessment methodology selection matters for TPRM programme effectiveness because mismatched methodology , low-depth assessment for high-criticality vendors , creates a false assurance gap: the vendor has been assessed, the assessment found no issues, but the assessment methodology was insufficient to find the issues that exist.
assessment methodology selection matters for TPRM programme effectiveness because mismatched methodology , low-depth assessment for high-criticality vendors , creates a false assurance gap: the vendor has been assessed, the assessment found no issues, but the assessment methodology was insufficient to find the issues that exist.
- Selecting the Right Network Security Assessment Methodology: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: technical evidence requirements for critical vendors; external scan integration for critical vendors; methodology review as part of TPRM governance.
- Sensitive Data Discovery Gaps
-
Sensitive data discovery is the systematic process of scanning an organization's data environment to identify where sensitive data , personal information, financial data, health information, credentials, and other regulated or high-value data categories , exists across storage systems, documents, collaboration platforms, and operational i
sensitive data discovery gaps matter for TPRM because they represent the category of data exposure that is invisible to standard vendor security assessments.
- Sensitive Data Discovery Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: discovery program scope documentation , all systems included with specific confirmation of support and collaboration platform coverage; most recent discovery scan results summary for support systems; remediation process documentation for out-of-scope sensitive data discoveries.
- Serverless Security in CI/CD
-
Serverless security matters for TPRM because over-permissive Lambda execution roles are a common finding in serverless environments that have not applied minimum-privilege principles to function IAM configuration.
serverless security matters for TPRM because over-permissive Lambda execution roles are a common finding in serverless environments that have not applied minimum-privilege principles to function IAM configuration.
- Serverless Security in CI/CD: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: execution role minimum privilege review records; IAM Access Analyzer or equivalent usage; iaC scanning for execution role security.
- Service auditor and service organisation
-
The service organization is the company being audited. The service auditor is the CPA firm performing the engagement. The user entity is the customer relying on the report, and the user auditor is that customer's own auditor, who may rely on the report in turn. The report is written for the last two.
knowing which role you occupy changes how you read the document. CUECs are written for the user entity and their auditor, which is why they read as instructions. The system description is written by the service organization about itself. The opinion is the service auditor's, addressed to the service organization's management.
- Session Hijacking Risks
-
Session hijacking is the attack technique of stealing the post-authentication session credential , typically a session cookie, access token, or refresh token , and using it to access systems as the authenticated user without repeating the authentication process.
session hijacking risk matters for TPRM because vendors who hold valid session tokens for customer environment access provide an additional attack vector beyond credential theft.
- Session Hijacking Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: access and refresh token lifetime documentation; continuous access evaluation implementation confirmation; session revocation capability and response time.
- Shadow AI
-
Shadow AI is the use of AI tools and features that nobody approved and nobody has recorded: consumer assistants used on personal accounts, models called from production code without review, and assistants switched on inside products the organization already buys. The last is the largest category and the least visible, because a vendor's new feature does not feel like adopting AI.
prohibition does not work. Banning a category without offering an approved alternative moves the activity onto personal accounts where you can see nothing. And a survey does not find it either, because people describe the tools they chose deliberately and not the feature that appeared in the support platform last quarter and now summarises every ticket.
- Shadow Cloud Usage by Vendors
-
Shadow cloud usage by vendors is the creation, modification, or operation of cloud resources within a customer's environment , or using the customer's cloud identity and billing , without the customer's explicit knowledge and approval of those specific activities.
shadow cloud usage by vendors is one of the clearest examples of how third-party risk in cloud environments cannot be assessed at the vendor organization level alone.
- Shadow Cloud Usage by Vendors: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: a clear description of what resource types the vendor requires access to create, with operational justification; evidence of internal controls preventing vendor engineers from provisioning unauthorized resources in customer environments; a defined decommissioning process for vendor-created resources at engagement close.
- SIEM Coverage Limitations
-
SIEM coverage limitations are the gaps between the systems and environments a SIEM platform monitors and the full technology footprint that generates security-relevant events. A SIEM platform monitors what it receives telemetry from , the systems, services, and environments that have been configured to forward logs and events to the SIEM.
SIEM coverage limitations matter for TPRM because supply chain attackers specifically target the less-monitored pathways into vendor environments , the managed services, the contractor access systems, and the development pipelines that are more likely to have gaps in their monitoring coverage.
- SIEM Coverage Limitations: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: managed service coverage confirmation or gap disclosure; a vendor with a mature SIEM should be asked for the integration inventory. SIEM deployment describes the capability. The inventory describes what the capability covers.
- SIG and SIG Lite
-
The Standardized Information Gathering questionnaire is a large structured question set maintained by the Shared Assessments programme, covering security, privacy, resilience and related domains. SIG Lite is the shorter core version. Their value is that a vendor may already have completed one, which turns your assessment into a review of existing answers rather than a fresh interrogation.
when your programme is deciding what instrument to use per tier, the standard sets are the obvious candidates for the top tier, and vendors selling into regulated buyers often keep a completed SIG current for exactly this reason. Accepting one saves both sides weeks, provided you read it rather than filing it.
- Sigstore and the Transparency Log Revolution
-
Sigstore matters for TPRM because it provides a free, accessible standard for software supply chain signing and transparency that removes the technical barrier to adoption for smaller vendors.
sigstore matters for TPRM because it provides a free, accessible standard for software supply chain signing and transparency that removes the technical barrier to adoption for smaller vendors.
- Sigstore and the Transparency Log Revolution: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: sigstore cosign adoption confirmation or roadmap; rekor log entry verification for recent releases; current signing approach and key management if not Sigstore.
- SLA vs Enforcement
-
Service Level Agreements define the performance standards that a vendor must meet , uptime percentages, response times, processing windows, and resolution timelines.
SLA vs enforcement matters for TPRM because SLAs are a primary contractual risk management tool , they establish performance standards that are supposed to ensure vendors deliver reliable, high-quality services.
- SLA vs Enforcement: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: root cause analysis for each SLA breach; specific remediation actions with timelines; infrastructure investment or operational changes planned.
- SOC 1, SOC 2 and SOC 3
-
A SOC 1 reports on controls relevant to a customer's financial reporting, and is what a customer's financial auditor wants from a payroll or billing provider. A SOC 2 reports against the Trust Services Criteria, for customers concerned with security and operations. A SOC 3 is a public, general-use summary of a SOC 2 with the testing detail removed.
a single vendor may hold two of these for different reasons, and being sent the wrong one wastes a review cycle. A payroll provider's SOC 1 says nothing about their security posture, and their SOC 2 says nothing about the accuracy of their financial processing.
- SOC 2 plus
-
A SOC 2 plus, sometimes written SOC 2+, is a SOC 2 engagement extended to report against additional criteria alongside the Trust Services Criteria, commonly ISO 27001, HIPAA, the CSA Cloud Controls Matrix or NIST CSF. The auditor maps the organization's controls to each framework and reports on all of them in one document.
for a vendor serving customers who ask for different frameworks, it is genuinely efficient. One evidence cycle, one audit, several assurance outputs. For a customer, it means the SOC 2 they receive may already answer their ISO or HIPAA questions without a separate exercise.
- SOC 2 Type I and Type II
-
A Type I report examines whether controls were suitably designed and in place on a single date. A Type II examines whether those controls actually operated, as described, across a period, usually three to twelve months. Both are issued under the same standard and look alike on the cover, which is where the confusion starts.
a Type I proves that a control existed on one day. A Type II proves that it kept working for months, through staff changes, releases and the ordinary pressure to skip a step. Procurement teams learned to ask for the second because the first says almost nothing about whether a vendor behaves consistently.
- SOC Automation Limitations
-
SOC automation limitations are the failure modes, coverage gaps, and drift vulnerabilities that prevent automated security operations tools , SOAR platforms, automated triage systems, and orchestration workflows , from reliably performing the functions they were deployed to perform.
SOC automation limitations matter for TPRM because SOAR deployment creates the appearance of improved detection coverage and analyst capacity without guaranteeing that the automation is correctly performing the functions it replaced.
- SOC Automation Limitations: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: last environmental alignment review date; change management SOAR integration procedure; a vendor who confirms SOAR deployment should be asked about playbook health monitoring. Deployment describes what was installed. Health monitoring describes whether what was installed is still correctly functioning. Environmental drift makes the distinction critical.
- Soft opt-in
-
The soft opt-in is an exception under ePrivacy rules that allows marketing by email or SMS without prior consent, where the recipient's details were obtained in the course of a sale or negotiation of a sale, the marketing is for similar products or services, and an opportunity to opt out was given at collection and in every subsequent message.
it is the basis most commonly claimed for marketing to existing customers, and it is frequently stretched beyond its terms. The exception requires a sale or the negotiation of one. It requires similar products. It requires the opt-out to have been offered at the moment the details were collected, not added later.
- Software bill of materials SBOM
-
A machine-readable parts list of every component in a build, with versions and relationships.
It is the inventory, not the deliverable. Published without exploitability judgements it hands customers a list of concerns they cannot rank.
Taught in CYB-201 · See also: Vulnerability exploitability exchange, Vulnerability management
- Software Bill of Materials , Beyond the Mandate
-
SBOM quality matters for TPRM because an SBOM that is stale, incomplete, or lacks vulnerability status information provides the appearance of supply chain transparency without the substance.
SBOM quality matters for TPRM because an SBOM that is stale, incomplete, or lacks vulnerability status information provides the appearance of supply chain transparency without the substance.
- Software Bill of Materials , Beyond the Mandate: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: version-specific SBOM in standard format (CycloneDX or SPDX); VEX documentation for components with known critical vulnerabilities; SBOM generation process and update cadence.
- Software Bill of Materials Automation
-
SBOM automation matters for TPRM because the intelligence value of an SBOM programme is proportional to the speed with which new CVEs in the inventory trigger enterprise awareness and action. A programme that reviews SBOMs annually at reassessment provides CVE awareness on a twelve-month lag.
SBOM automation matters for TPRM because the intelligence value of an SBOM programme is proportional to the speed with which new CVEs in the inventory trigger enterprise awareness and action.
- Software Bill of Materials Automation: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: cycloneDX JSON format SBOM for current deployed version; CVE notification process for component vulnerabilities; SBOM update cadence , how frequently updated.
- Software Composition Analysis Gaps
-
SCA gaps matter for TPRM because the 'zero critical vulnerabilities' report from an SCA tool only covers what the tool was configured to scan.
SCA gaps matter for TPRM because the 'zero critical vulnerabilities' report from an SCA tool only covers what the tool was configured to scan.
- Software Composition Analysis Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SCA scope documentation , repositories and ecosystems covered; scan frequency and integration with development workflow; a vendor who confirms SCA tool implementation should be asked for scope documentation. Tool existence confirms the capability. Scope documentation reveals what the capability covers and what it misses.
- Software Composition Analysis in CI/CD
-
SCA coverage in CI/CD matters for TPRM because software vulnerability exposure is determined by the worst-covered component, not the best-covered one.
SCA coverage in CI/CD matters for TPRM because software vulnerability exposure is determined by the worst-covered component, not the best-covered one.
- Software Composition Analysis in CI/CD: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SCA coverage map with all production repositories; dependency update bot PR merge rate for critical findings; CI/CD enforcement configuration for SCA.
- Software Provenance Verification
-
Software provenance verification matters for TPRM because distribution infrastructure compromises are a documented attack vector , the mechanism used in the NotPetya attack (through M.E.Doc update infrastructure), the ASUS Live Update attack, and similar supply chain incidents.
software provenance verification matters for TPRM because distribution infrastructure compromises are a documented attack vector , the mechanism used in the NotPetya attack (through M.E.Doc update infrastructure), the ASUS Live Update attack, and similar supply chain incidents.
- Software Provenance Verification: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SLSA provenance attestation for specific releases; transparency log entry verification process; a vendor who confirms signed releases should be asked about provenance attestation verification. Signature confirms the key signed the artifact. Provenance attestation confirms the build system produced what the key signed. The distribution infrastructure compromise bypasses signature if the attacker also had signing access. Provenance attestation logged to an immutable transparency log before the compromise is the evidence that the compromise cannot erase.
- Software Supply Chain for SaaS Products
-
SaaS supply chain security matters for TPRM because the enterprises that have invested most heavily in installed software supply chain controls , SBOMs, SCA, provenance , are simultaneously dependent on SaaS services whose supply chain security is managed entirely by the vendor.
saaS supply chain security matters for TPRM because the enterprises that have invested most heavily in installed software supply chain controls , SBOMs, SCA, provenance , are simultaneously dependent on SaaS services whose supply chain security is managed entirely by the vendor.
- Software Supply Chain for SaaS Products: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: saaS platform SBOM or equivalent dependency inventory; open-source dependency vulnerability monitoring programme; build pipeline compromise detection and notification process.
- Software Supply Chain Security
-
Software supply chain security is about one fundamental question: can you trust not just the software a vendor delivers, but the entire process that produced it? Most security controls focus on what software does once it is running , scanning for vulnerabilities, monitoring for anomalies, controlling access.
traditional third-party assessments treat the vendor as the unit of risk , their controls, their certifications, their policies.
- Software Supply Chain Security: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: a machine-readable SBOM in CycloneDX or SPDX format, current within the last release; documentation of artifact signing and key management practices; evidence that pipeline credentials are short-lived and scoped , not static and broad.
- Software Update Mechanism Security
-
Update mechanism security matters for TPRM because software vendors who deliver products with auto-update mechanisms are delivering a persistent code deployment channel into the enterprise's environment.
update mechanism security matters for TPRM because software vendors who deliver products with auto-update mechanisms are delivering a persistent code deployment channel into the enterprise's environment.
- Software Update Mechanism Security: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: update mechanism security architecture description; Certificate/key management and rotation policy; compromise notification process for update infrastructure.
- Software-Defined Perimeter for Vendor Access
-
SDP for vendor access matters for TPRM because network-level trust established for one vendor does not automatically contract when that vendor's ownership, security posture, or personnel changes.
SDP for vendor access matters for TPRM because network-level trust established for one vendor does not automatically contract when that vendor's ownership, security posture, or personnel changes.
- Software-Defined Perimeter for Vendor Access: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: ownership change history since access establishment; contract provision for ownership change notification; access reassessment upon any ownership change.
- Special category data sensitive data
-
Categories carrying extra protection: health, racial or ethnic origin, beliefs, union membership, sexual orientation, biometric and genetic data.
Misuse causes disproportionate harm, so the handling rules are stricter wherever these appear, including inside an ordinary support ticket.
Taught in PRV-201 · See also: Personal data
- SSAE 18 and AT-C 205
-
SSAE 18 is the attestation standard issued by the AICPA under which SOC engagements are performed in the United States. AT-C section 205 within it covers examination engagements, which is what a SOC 2 is. The standard governs how the engagement is planned, performed and reported, and who may perform it.
it explains why a SOC 2 can only be issued by a licensed CPA firm, however capable a security consultancy might be, and why the report carries a firm's name, licence and independence obligations. It also explains why the auditor cannot fix what they find, because the standard requires their independence from the controls examined.
- Standard contractual clauses
-
Standard contractual clauses are the European Commission's approved contract terms for transferring personal data to a third country. The 2021 version is modular: module one covers controller to controller, module two controller to processor, module three processor to processor, and module four processor to controller. The parties select the module matching their actual relationship.
the module must match how the data actually flows. A controller exporting to a processor who signs module one has a contract that does not describe the transfer, and the transfer has no valid mechanism. Vendors frequently offer their default module without regard to the customer's role.
- Statement of Applicability SoA
-
The ISO 27001 document listing every Annex A control with whether it applies, the justification, and its implementation status.
It is referenced by the certificate and read first at every audit. Exclusions are expected; the justification has to be about relevance, not difficulty.
Taught in GRC-202 · See also: IT general controls, Risk treatment
- Structured vs Unstructured Data Risk
-
The unstructured data risk dimension matters for TPRM because vendor assessments that focus on structured data security , database encryption, access controls, audit logging , systematically miss the majority of the data surface where customer-sensitive information is likely to exist and least likely to be governed.
the unstructured data risk dimension matters for TPRM because vendor assessments that focus on structured data security , database encryption, access controls, audit logging , systematically miss the majority of the data surface where customer-sensitive information is likely to exist and least likely to be governed.
- Structured vs Unstructured Data Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: comprehensive data inventory including unstructured repositories alongside primary databases; data discovery tool coverage confirmation , unstructured repositories included in discovery and classification scope; collaboration platform governance evidence , access controls, DLP policies, and audit logging enabled.
- Sub-processors
-
A sub-processor is a third party engaged by a processor to carry out processing on the controller's behalf. Article 28 requires the processor to obtain the controller's prior authorisation, either specific to each sub-processor or general with notice of changes and an opportunity to object, and to flow down the same obligations by contract.
a vendor's sub-processor list is where your actual data footprint becomes visible, and it is usually longer than expected. A SaaS product may involve a hosting provider, a support tool, an email service, an analytics platform, a payment processor and a monitoring service, each of which handles some of your data.
- Subprocessor Visibility
-
Subprocessor visibility matters because the enterprise's data protection obligations , and its supply chain risk exposure , extend to all of the vendor's subprocessors regardless of whether those subprocessors are disclosed.
subprocessor visibility matters because the enterprise's data protection obligations , and its supply chain risk exposure , extend to all of the vendor's subprocessors regardless of whether those subprocessors are disclosed.
- Subprocessor Visibility: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: prior notification commitment for new subprocessors; functional subprocessor test application evidence; a vendor who provides a DPA subprocessor list should be asked for the production technology stack alongside it. The DPA list is the disclosed subprocessors. The production stack reveals the actual processing environment. The gap between them is the subprocessor visibility risk.
- Subsequent events
-
Events that occur after the observation period ends but before the report is issued may need to be disclosed in the report if they affect the fair presentation of the system description or the reader's understanding of the controls. A breach, a major outage, a change of ownership or a material control failure in that window are the usual candidates.
the period bounds the testing, not the disclosure obligation. A breach in the weeks between period end and issuance is precisely this situation, and a report that says nothing about it is not neutral. Management has an obligation to inform the auditor, and the auditor has an obligation to consider it.
- Subservice organisation carve-out
-
A vendor of your vendor whose controls matter to the service you receive, either included in the report or carved out of it and named.
A carve-out is a boundary, not a finding. It tells you which control objectives depend on a company whose report you do not yet hold.
Taught in TPR-210 · See also: Complementary user entity control, Fourth party
- Subservice organisations
-
A subservice organization is a vendor whose controls your own service depends on to meet a criterion. Your cloud host. Your payment processor. The managed detection provider watching your logs. The test is dependency, not spend: a vendor qualifies if a criterion cannot be met without their controls operating.
you cannot test another company's controls and neither can your auditor, so the report has to say something about them, and how it does that shapes the whole document. The subservice organizations named in a report tell a reader where the audited company's assurance stops and somebody else's begins.
- Subservice provider concentration in reports
-
Your vendor's SOC 2 carves out their hosting provider. The hosting provider's report carves out a colocation facility. The facility's report references a power and connectivity provider. The chain continues below the point where anyone ordinarily reads, and assurance thins with every layer.
concentration risk lives at the bottom of the stack. Twenty of your vendors may each carve out the same hyperscaler, in the same region, and each report looks fine individually. The dependency is only visible when the chain is traced and the reports are read together.
- Supply Chain AI Trust Boundaries
-
AI trust boundaries define the scope of what an AI system should and should not do, reveal, or enable based on who is asking and in what context.
AI trust boundaries matter for TPRM because vendor AI products that aggregate sensitive operational information into queryable knowledge bases create reconnaissance capabilities that extend to any user who can authenticate , including users with compromised credentials, social engineering attacks, and insider threats with credentials exce
- Supply Chain AI Trust Boundaries: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: knowledge base sensitive content assessment; context-aware access controls beyond authentication; a vendor who confirms AI authentication controls should be asked about trust boundary scope. Authentication confirms identity. Trust boundary scope determines whether the authenticated identity's request falls within the appropriate access scope for sensitive information.
- Supply Chain Attack Detection
-
Supply chain attack detection matters for TPRM because the vendor whose production security monitoring is excellent but whose build pipeline generates no SOC signals has a detection gap for exactly the attack vector that supply chain attacks use.
supply chain attack detection matters for TPRM because the vendor whose production security monitoring is excellent but whose build pipeline generates no SOC signals has a detection gap for exactly the attack vector that supply chain attacks use.
- Supply Chain Attack Detection: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: build pipeline monitoring scope and log ingestion; supply chain-specific detection rules in SIEM; expected detection timeframe for build pipeline compromise.
- Supply chain attacks
-
A supply chain attack compromises a trusted supplier, a software component or an update mechanism in order to reach the supplier's customers all at once. Rather than attacking a thousand organizations, the attacker compromises the one thing those thousand share: a build pipeline, a widely used library, a managed service provider's remote access tool, or a vendor's signing key.
it is the reason third-party risk stopped being a procurement formality. The attacks that reached the most organizations in recent years arrived through trusted software updates and through service providers with legitimate access, not through the victims' own perimeters. Your controls were operating. The trust you had placed in a supplier was the vulnerability.
- Supply Chain Incident Response
-
Supply chain incident response matters for TPRM because the vendor whose IR programme is mature for production incidents but has no supply chain playbook will be significantly less effective in responding to a supply chain compromise , and the enterprise whose vendor has been compromised will receive slower notification, less complete inf
supply chain incident response matters for TPRM because the vendor whose IR programme is mature for production incidents but has no supply chain playbook will be significantly less effective in responding to a supply chain compromise , and the enterprise whose vendor has been compromised will receive slower notification, less complete inf
- Supply Chain Incident Response: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: supply chain incident playbook existence; customer deployment inventory and notification process; supply chain tabletop exercise records.
- Supply Chain Risk in Mergers and Acquisitions
-
Supply chain risk in M&A matters because software dependency technical debt , accumulated over years of feature-velocity-over-security prioritisation , is not visible in standard technology due diligence but is directly inherited by the acquiring enterprise.
supply chain risk in M&A matters because software dependency technical debt , accumulated over years of feature-velocity-over-security prioritisation , is not visible in standard technology due diligence but is directly inherited by the acquiring enterprise.
- Supply Chain Risk in Mergers and Acquisitions: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: current SBOM from production codebase; EOL dependency identification with remediation assessment; critical vulnerability inventory with patching status.
- Supply Chain Risk Quantification
-
Supply chain risk quantification matters because it converts risk documentation into risk management. CISO and board audiences need financial exposure estimates to make investment decisions, prioritise competing security initiatives, and communicate risk posture to stakeholders who make resource allocation decisions.
supply chain risk quantification matters because it converts risk documentation into risk management.
- Supply Chain Risk Quantification: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: risk quantification methodology for supply chain risks; financial exposure estimates for critical supply chain scenarios; investment prioritisation based on quantified risk.
- Supply Chain Security in CI/CD Pipelines
-
CI/CD pipeline supply chain security matters for TPRM because a vendor who confirms application dependency scanning without confirming pipeline component security has addressed one supply chain attack surface while leaving another unaddressed.
CI/CD pipeline supply chain security matters for TPRM because a vendor who confirms application dependency scanning without confirming pipeline component security has addressed one supply chain attack surface while leaving another unaddressed.
- Supply Chain Security in CI/CD Pipelines: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: pipeline component inventory with SHA pinning status; pipeline action maintainer monitoring implementation; build tool installation verification process.
- Supply Chain Security in Regulated Industries
-
Regulated industry supply chain security matters for TPRM because enterprises in regulated sectors face specific, documented regulatory requirements that their vendors must also comply with , and that general supply chain security assessments may not address in the required format.
regulated industry supply chain security matters for TPRM because enterprises in regulated sectors face specific, documented regulatory requirements that their vendors must also comply with , and that general supply chain security assessments may not address in the required format.
- Supply Chain Security in Regulated Industries: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: regulatory-format SBOM and VEX for medical device vendors; DORA ICT supply chain provision compliance for financial services; regulatory submission examples with supply chain documentation.
- Supply Chain Security Maturity Assessment
-
Supply chain security maturity assessment matters for TPRM because it provides the domain-specific picture of where supply chain security investment has been made and where the gaps are , which directly informs both internal programme improvement prioritisation and the questions that TPRM teams should ask of vendors about the specific dom
supply chain security maturity assessment matters for TPRM because it provides the domain-specific picture of where supply chain security investment has been made and where the gaps are , which directly informs both internal programme improvement prioritisation and the questions that TPRM teams should ask of vendors about the specific dom
- Supply Chain Security Maturity Assessment: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: domain-specific maturity ratings for six supply chain security domains; level 0 acknowledgment for absent domains rather than N/A; investment roadmap for lowest-maturity domains.
T
- Tabletop exercises
-
A tabletop exercise walks the people who would respond to an incident through a realistic scenario, in a room, without touching any system, to find out where the plan breaks. Ninety minutes, the actual responders, no preparation, and a decision log kept throughout. The output is not a score; it is the changes to the runbook that the exercise exposed.
incident plans are written by people imagining an incident, and they behave differently under the pressure of a real one. The tabletop is the only way to find that difference before it costs something. It also comes up because frameworks and insurers ask whether the plan is tested, and a plan tested once, twenty months ago, before the current lead joined, is not tested in any sense that matters.
- Testing periods and gaps between reports
-
A Type II report covers a defined period. The next report covers the next period. But reports are issued weeks or months after their period ends, and periods do not always abut. A vendor with an annual report can leave a customer with several months each year that no report covers.
a customer who records the report date rather than the period covered does not know when their assurance lapsed. Bridge letters exist to address exactly this, and knowing the gap is what tells you when to ask for one.
- The carve-out method
-
Under the carve-out method, a subservice organization's controls are excluded from the audit. The report describes what the audited company relies on that provider to do, states that those controls were not tested, and lists them as complementary subservice organization controls. It is the method nearly every SOC 2 uses, because the alternative requires the provider's participation.
this is why a vendor's SOC 2 can contain controls attributed to AWS or Azure that nobody in the engagement tested. The audited company relies on them, states the reliance, and the auditor's opinion covers only what the company itself operates.
- The Common Criteria, CC1 to CC9
-
The Security category is organised into nine groups called the Common Criteria. CC1 covers the control environment, CC2 communication, CC3 risk assessment, CC4 monitoring, CC5 control activities, CC6 logical and physical access, CC7 system operations and incident response, CC8 change management, and CC9 risk mitigation including vendor management. Every SOC 2 addresses all nine.
the groups are not equal in effort or in risk. CC6 alone covers provisioning, authentication, authorisation, removal, physical access and data disposal, touches every system, and produces more exceptions than any other group. CC1 and CC2 are largely governance and documentation. Knowing which is which changes how you read a report and how you plan an audit.
- The controller
-
The controller is whoever determines the purposes and means of processing personal data: why it is processed and, in broad terms, how. The title follows the decision, not the contract. A company that decides what data to collect and what to do with it is the controller for that processing, regardless of what any agreement calls it.
the controller carries the primary obligations: lawful basis, transparency, data subject rights, breach notification, accountability. A vendor that starts using your customers' data for its own product improvement has made a purpose decision, and has become a controller for that use, whatever the DPA says about it being a processor.
- The five trust services categories
-
Security, Availability, Processing Integrity, Confidentiality and Privacy are the five categories a SOC 2 can cover. Only Security is required. The other four are optional, chosen by the audited company, and most reports include Security alone or Security with Availability.
when someone says they have a SOC 2, they almost always mean Security. If what you need assurance about is uptime, data handling or personal information, the report may not address it at all, and the cover page says so in a single line most readers do not check.
- The Future of DevSecOps
-
The future of DevSecOps matters for TPRM because the vendors whose software enterprises will depend on in five years are building that software today , with today's DevSecOps programmes plus whatever forward investment they are making in the five trajectories above.
the future of DevSecOps matters for TPRM because the vendors whose software enterprises will depend on in five years are building that software today , with today's DevSecOps programmes plus whatever forward investment they are making in the five trajectories above.
- The Future of DevSecOps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: devSecOps programme roadmap for 3-year horizon; AI code security approach and timeline; SLSA adoption target and timeline.
- The Future of Network Security , Five Trends Reshaping the Perimeter
-
Traditional Perimeter: Dissolving. Identity: The New Perimeter.
the future of network security matters for TPRM because vendors who are building for the future network security landscape , adopting SASE, developing AI-driven detection, planning post-quantum transitions , are vendors whose security posture will be more appropriate for the threat landscape of 2028 than vendors who are maintaining the ar
- The Future of Software Supply Chain Security
-
The future of supply chain security matters for TPRM because programme investments made today should account for the capabilities that will be required in three to five years , not just the current state.
the future of supply chain security matters for TPRM because programme investments made today should account for the capabilities that will be required in three to five years , not just the current state.
- The Future of Software Supply Chain Security: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: AI code generation governance policy; review depth requirements for AI-generated code; post-quantum cryptography transition awareness and planning.
- The Future of TPRM , From Assurance to Intelligence
-
The shift from assurance to intelligence matters because it addresses the fundamental limitation of point-in-time assessment: its inability to predict what will happen next.
the shift from assurance to intelligence matters because it addresses the fundamental limitation of point-in-time assessment: its inability to predict what will happen next.
- The Future of TPRM , From Assurance to Intelligence: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: predictive risk scoring capability or roadmap; historical pattern analysis from programme data; external signal integration for trend prediction.
- The inclusive method
-
The inclusive method is the alternative to carve-out. The subservice organization's relevant controls are described and tested inside the audited company's own report, so a reader is not asked to assume anything about the layer beneath. The opinion genuinely covers the stack.
it produces stronger assurance than carve-out, and buyers occasionally ask why a vendor did not use it. The answer is practical. The subservice organization has to agree to be included, to be described in the system description, and to sign its own management assertion for the engagement.
- The legitimate interests assessment
-
A legitimate interests assessment, LIA, is the documented reasoning that supports relying on legitimate interests as a lawful basis. It has three parts. The purpose test: what is the interest, and is it legitimate. The necessity test: is the processing necessary for that interest, or could it be achieved another way. The balancing test: does the interest outweigh the individual's rights and reasonable expectations.
most B2B processing, most fraud prevention, most security monitoring and much analytics rests on legitimate interests. Regulators ask to see the assessment, not the assertion. A controller who says legitimate interests but cannot produce the reasoning has, in the regulator's eyes, not done the assessment.
- The management assertion
-
Before the auditor's opinion sits management's assertion: a signed statement by the audited company that the system description is accurate and that the controls were suitably designed and, for a Type II, operated effectively. The auditor's opinion is an opinion on that assertion.
everything in the report rests on management having described their system truthfully. If the description understates scope, omits a component or misrepresents a boundary, every clean test result is a test of a smaller thing than the reader assumed, and the auditor's opinion, while accurate, is about that smaller thing.
- The NIST AI Risk Management Framework
-
The NIST AI Risk Management Framework is a voluntary structure for managing the risks of AI systems across four functions. Govern establishes accountability and culture. Map identifies the context, the people affected and the risks. Measure assesses those risks, including performance across the groups the system affects. Manage acts on what was measured, through oversight and monitoring. It tells you how to work, where a regulation tells you what you must do.
it is the reference most assessment processes borrow from, whether or not they cite it, and it is the framework a buyer or a regulator will recognise when you describe how you assess AI risk. It pairs naturally with the EU AI Act: the Act classifies and obliges, the RMF gives you the method for meeting the obligations.
- The observation period
-
The observation period is the window across which a Type II audit tested control operation. It is stated in the opinion and usually spans three, six or twelve months. Both a three-month and a twelve-month period produce a valid report.
a three-month period covers one quarterly access review at most, possibly none. A twelve-month period covers four, plus a year-end, a holiday season, at least one reorganization and several releases. The longer period is a far stronger statement about whether controls hold under normal pressure.
- The processor
-
A processor processes personal data on behalf of a controller, acting only on the controller's documented instructions. It does not decide why the data is processed. Its obligations are narrower than a controller's but real: security, confidentiality, sub-processor management, assistance with rights requests, and deletion or return at the end.
the moment a processor decides a purpose of its own, it stops being a processor for that activity and takes on controller obligations directly. The most common example is analytics: a SaaS provider running customer data through its own models to improve the product has made a purpose decision that the customer did not instruct.
- The right to erasure
-
The right to erasure, often called the right to be forgotten, allows a person to require deletion of their personal data in specific circumstances: the data is no longer necessary, consent is withdrawn, they object and there is no overriding ground, the processing was unlawful, or a legal obligation requires deletion. It is one of the most requested rights and among the least correctly applied.
it is not absolute. It is overridden where processing is necessary for compliance with a legal obligation, for the establishment or defence of legal claims, for freedom of expression, for public health, or for archiving in the public interest. A controller who deletes everything on request may have destroyed records the law required them to keep.
- The SolarWinds Lessons Still Unlearned
-
The unlearned SolarWinds lessons matter for TPRM because they represent a systematic gap between current supply chain attack capabilities and the assessment questions that most TPRM programmes ask.
the unlearned SolarWinds lessons matter for TPRM because they represent a systematic gap between current supply chain attack capabilities and the assessment questions that most TPRM programmes ask.
- The SolarWinds Lessons Still Unlearned: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: build pipeline isolation and monitoring controls; signing key protection , HSM or equivalent; update mechanism security and enterprise governance.
- The system description
-
The system description is the audited company's own account of the system in scope: what the service does, the infrastructure and software involved, the people and processes, the data handled, and the boundary around it all. The auditor examines whether it is fairly presented. The company writes it.
the description decides what was audited. A description that draws the boundary narrowly, around a well-controlled core and away from the newer, messier services, produces an easier audit and a report that covers less than a reader assumes. Nothing about that is improper, but a reader who does not compare the description against the service they actually use has no idea what the opinion covers.
- Third-Party Actions and Reusable Workflows
-
Shared workflow and reusable action security matters for TPRM because a single compromised shared workflow can be the supply chain entry point for every service in a vendor's portfolio.
shared workflow and reusable action security matters for TPRM because a single compromised shared workflow can be the supply chain entry point for every service in a vendor's portfolio.
- Third-Party Actions and Reusable Workflows: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: shared workflow repository access controls; review requirements for shared workflow changes; SHA pinning within shared workflows.
- Third-Party AI Integrations
-
Third-party AI integration risks are the security, compliance, governance, and operational risks created when enterprise SaaS platforms embed AI capabilities , features powered by machine learning models, large language models, or AI-driven automation , within their products.
third-party AI integrations matter for TPRM because the most consequential AI in an enterprise's stack is often embedded in standard SaaS platforms rather than deployed as standalone AI products.
- Third-Party AI Integrations: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: AI feature inventory with data access scope; training data documentation for consequential AI features; fairness assessment for AI features affecting individuals.
- Third-Party Audit Reliance
-
Third-party audit reports , SOC 2, ISO 27001, PCI-DSS attestations, penetration test reports from reputable firms , provide valuable assurance evidence. They represent the professional judgment of independent specialists who have examined the vendor's controls against defined criteria.
third-party audit reliance matters for TPRM because audit reports are the most commonly accepted and most heavily weighted evidence in vendor assessments , and their value depends on factors that are specific to each report and each customer relationship, not on the firm's reputation or the report's clean opinion.
- Third-Party Audit Reliance: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: scope confirmation for customer-relevant systems; methodology description for customer-relevant control categories; supplemental assessment for any scope exclusions affecting customer data.
- Third-party incident notification
-
When a vendor is breached, your own notification obligations to regulators and customers may run from the moment you become aware, which can be the moment you read the news rather than the moment the vendor confirms anything. The vendor's contractual clock to tell you and your regulatory clock to tell others are different clocks, and the second does not wait for the first.
a company learns of a supplier's compromise from a webpage, spends a weekend deciding whether it counts as a breach and whether its clock has started, and misses a customer contract deadline by a day. All three questions had standing answers that could have been written months earlier, and the weekend was spent on law instead of forensics.
- Third-party risk management
-
Third-party risk management is the discipline of knowing which outside organizations touch your data, your systems or your customers, assessing them in proportion to that exposure, contracting for what matters, watching for the events that change their risk, and getting your data back when the relationship ends. Five stages. Most programmes are built around the second one and neglect the other four.
every framework you are assessed against asks about it, every enterprise buyer asks about it, and a growing set of regulators ask to see the register. It also comes up because the breach that reaches you most often is not yours. It is a supplier's, and the questionnaire they completed at onboarding said nothing about the subprocessor that was actually compromised.
- Third-Party SDK Risk
-
SDK risk matters for TPRM because SDKs in enterprise mobile and web applications create data collection and transmission risks that the enterprise may not be fully aware of , and that change over time as SDK providers update their products.
SDK risk matters for TPRM because SDKs in enterprise mobile and web applications create data collection and transmission risks that the enterprise may not be fully aware of , and that change over time as SDK providers update their products.
- Third-Party SDK Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SDK inventory with data collection behaviour documentation; SDK update review process for privacy-relevant changes; network traffic analysis results for high-risk SDKs.
- Third-Party vs Fourth-Party Risk
-
Fourth-party risk is the security risk created by the vendors of your vendors , the subprocessors, sub-service providers, and supply chain participants that your third parties use to deliver their services to you.
fourth-party risk matters because data breaches do not respect the organizational boundaries of the dependency chain.
- Third-Party vs Fourth-Party Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: complete subprocessor inventory with functions and data categories; subprocessor security certifications , SOC 2 or equivalent; breach notification chain timeline documentation.
- Threat Detection Blind Spots
-
Threat detection blind spots are the gaps in a security monitoring programme's ability to detect attack activity , the attack techniques, attacker behaviours, and malicious activity patterns that the monitoring programme's current detection logic does not identify as anomalous or malicious.
threat detection blind spots matter for TPRM because a vendor's detection capability assessment typically confirms the existence and configuration of the detection programme rather than testing its effectiveness against realistic current attack techniques.
- Threat Detection Blind Spots: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: red team or purple team exercise methodology , whether LotL techniques were included; detection rate for LotL techniques in last exercise; ATT&CK coverage map or coverage percentage.
- Threat Hunting Across Vendors
-
Threat hunting is the proactive, hypothesis-driven search for attacker activity in an environment , searching for indicators of compromise that automated detection has not flagged, based on threat intelligence about specific attacker techniques, known attacker behaviours, or anomaly patterns consistent with malicious activity.
threat hunting across vendor environments matters for TPRM because sophisticated supply chain attackers specifically target the environments that are most likely to be out of scope for standard threat hunts , the CI/CD pipeline, the development environment, the contractor access system, and the managed services.
- Threat Hunting Across Vendors: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: most recent hunt scope documentation; CI/CD inclusion confirmation or exclusion rationale; a vendor who confirms proactive threat hunting should be asked whether the hunt scope covered the specific environments the triggering intelligence identified as high-risk. Hunt activity is the evidence of programme operation. Scope alignment is the evidence of programme effectiveness.
- Threat Intel Integration Gaps
-
Threat intelligence integration gaps are the delays, coverage limitations, and workflow failures that prevent threat intelligence from being operationalised into active detection in the timeframe that the threat landscape requires.
threat intel integration gaps matter for TPRM because a vendor's threat intelligence subscription and platform investment only translates to detection improvement if the intelligence reaches the SIEM in time to detect the threat it describes.
- Threat Intel Integration Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: integration cadence by IOC category; integration latency metric , time from publication to detection activation; a vendor who confirms TI-SIEM integration should be asked the 11am scenario question. The integration exists describes the connection. The answer to the scenario question describes when the connection delivers value.
- Threat intelligence
-
Information about breaches, vulnerabilities and attacker behaviour, matched against what you hold, use and depend on.
Without inventories to match against it produces reading rather than action. Measure the programme by decisions, not by items processed.
Taught in CYB-210 · See also: Vulnerability management, Concentration risk
- Threat Intelligence for Supply Chain Attacks
-
Threat intelligence operationalisation matters for TPRM because supply chain threat intelligence provides the forward-looking risk signal that historical assessments cannot , it describes what attackers are doing now, which sectors they are targeting, and which attack vectors they are using.
threat intelligence operationalisation matters for TPRM because supply chain threat intelligence provides the forward-looking risk signal that historical assessments cannot , it describes what attackers are doing now, which sectors they are targeting, and which attack vectors they are using.
- Threat Intelligence for Supply Chain Attacks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: vendor awareness of the described threat advisory; assessment of exposure to described attack vectors; remediation or mitigation actions taken in response.
- Threat Modelling in the SDLC
-
Threat modelling matters for TPRM because it is the only security activity that can reliably catch design-level vulnerabilities before implementation.
threat modelling matters for TPRM because it is the only security activity that can reliably catch design-level vulnerabilities before implementation.
- Threat Modelling in the SDLC: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: recent threat model example with triggering feature; mitigation tracking from threat model to implementation; threat modelling methodology and tools used.
- Tiered Reassessment Frequency
-
Tiered reassessment frequency matters because TPRM capacity is limited. Every assessment cycle consumed by a low-risk vendor that has not materially changed is a cycle not available for a high-risk vendor whose risk profile has evolved since their last assessment.
tiered reassessment frequency matters because TPRM capacity is limited.
- Tiered Reassessment Frequency: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: material change disclosure since last assessment; proactive notification commitment for between-assessment changes; trust report or security changelog for the period.
- TLS Inspection and Encrypted Traffic
-
TLS inspection security matters for TPRM because vendors who deploy TLS inspection without appropriate private key protection and appliance patching have created a cryptographic risk that inverts the security purpose of TLS inspection.
TLS inspection security matters for TPRM because vendors who deploy TLS inspection without appropriate private key protection and appliance patching have created a cryptographic risk that inverts the security purpose of TLS inspection.
- TLS Inspection and Encrypted Traffic: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: HSM implementation for CA private key; inspection appliance patching schedule and last patch date; TLS inspection trust scope limitation.
- Token Persistence Risks
-
Token persistence risk is the security exposure created by OAuth access tokens, API tokens, and other bearer credentials that remain valid beyond the operational life of the application, integration, or use case that requested them.
token persistence risk matters for TPRM because platforms that hold OAuth tokens for vendor integrations are accumulating credentials that outlast the integrations they support.
- Token Persistence Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: OAuth token inventory with last-use dates and application associations; token revocation process documentation including application deprecation trigger; token expiry policy , maximum validity periods for issued tokens.
- Tokenization vs Masking Confusion
-
Tokenization and data masking are both techniques for replacing sensitive data values with non-sensitive substitutes in systems where the original value is not required for the primary function.
tokenization and masking confirmation is frequently cited as evidence of sensitive data protection in payment, healthcare, and financial services vendor assessments.
- Tokenization vs Masking Confusion: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: detokenization access list with review history , who has access, last reviewed, justification documented; detokenization audit log confirmation , logging in place, review process defined; masking consistency policy , contexts receiving masked vs unmasked values documented.
- TPRM as a Business Enabler
-
The business enabler framing matters because it determines the TPRM programme's sustainability. Programmes that generate business friction without corresponding business value face escalating pressure to be bypassed, de-resourced, or replaced with lower-burden compliance alternatives.
the business enabler framing matters because it determines the TPRM programme's sustainability.
- TPRM as a Business Enabler: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: SOC 2 report and relevant certifications ready to provide; designated security contact for assessment facilitation; a vendor who wants to be onboarded quickly should be asked for their pre-qualification package. Vendors who have invested in making themselves easy to assess help the enterprise run a faster, better-quality TPRM process. That investment is itself a positive signal.
- TPRM Board and Executive Reporting
-
Board reporting matters because it is the mechanism through which board-level risk governance of third-party relationships is exercised. A board that does not receive the information needed to ask informed questions about third-party risk is a board that cannot provide effective risk oversight.
board reporting matters because it is the mechanism through which board-level risk governance of third-party relationships is exercised.
- TPRM Board and Executive Reporting: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: board risk committee reporting on TPRM; material risk identification at board level; a vendor who confirms mature TPRM governance should be asked whether that governance reaches the board level. Operational programme maturity is not the same as board-level risk oversight.
- TPRM for Mergers and Acquisitions
-
M&A TPRM matters because the risk of inheriting undisclosed vendor relationships, active security incidents, and restricted vendor contracts is real, quantifiable, and preventable through pre-close due diligence.
m&A TPRM matters because the risk of inheriting undisclosed vendor relationships, active security incidents, and restricted vendor contracts is real, quantifiable, and preventable through pre-close due diligence.
- TPRM for Mergers and Acquisitions: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: complete vendor list with data access characterisation; open TPRM findings at any severity; an acquisition target should be asked for their vendor portfolio, open findings, and incident history as M&A due diligence. That information determines the third-party risk the enterprise is acquiring , which should be priced and managed, not discovered eighteen months post-close.
- TPRM Ownership and Accountability Gaps
-
Ownership and accountability gaps matter because identified risks that remain unmanaged are not less dangerous than unidentified risks , they are more dangerous, because the organization has documented awareness of the risk and cannot claim ignorance in a post-incident review or regulatory examination.
ownership and accountability gaps matter because identified risks that remain unmanaged are not less dangerous than unidentified risks , they are more dangerous, because the organization has documented awareness of the risk and cannot claim ignorance in a post-incident review or regulatory examination.
- TPRM Ownership and Accountability Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: formal finding remediation response process; escalation contact for unresolved critical findings; remediation timeline commitment for critical findings.
- TPRM Programme Automation and Its Limits
-
Automation limits matter because the efficiency gains from TPRM automation are real and valuable, but they must be achieved without compromising the analytical quality that makes the programme's risk intelligence useful.
automation limits matter because the efficiency gains from TPRM automation are real and valuable, but they must be achieved without compromising the analytical quality that makes the programme's risk intelligence useful.
- TPRM Programme Automation and Its Limits: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: human review step in automated assessment workflow; evidence cross-checking process alongside questionnaire scoring; quality metrics alongside efficiency metrics.
- TPRM Programme Maturity Models
-
TPRM maturity assessment matters because it provides the structured analysis needed to prioritise programme investment.
TPRM maturity assessment matters because it provides the structured analysis needed to prioritise programme investment.
- TPRM Programme Maturity Models: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: regulatory framework alignment for each domain; programme improvement roadmap driven by maturity gaps; independent validation of maturity assessment.
- TPRM Programme Metrics & KPIs
-
Programme metrics matter because they determine whether TPRM investment is justified and where it should be directed. A programme measured only on process completion metrics cannot demonstrate value to leadership or identify where programme improvements would have the greatest risk reduction impact.
programme metrics matter because they determine whether TPRM investment is justified and where it should be directed.
- TPRM Programme Metrics & KPIs: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: finding rate by vendor tier; remediation rate and average timeline; a vendor who confirms a mature TPRM programme should be asked for their risk outcome metrics. Process completion tells you they are running the programme. Risk outcome metrics tell you what it has accomplished.
- TPRM Questionnaire Design Failures
-
Questionnaire design matters because the quality of the risk intelligence that drives TPRM decisions is bounded by the quality of the information the questionnaire generates. A well-designed questionnaire that asks the right forty questions produces better risk intelligence in less time than a poorly designed 187-question questionnaire.
questionnaire design matters because the quality of the risk intelligence that drives TPRM decisions is bounded by the quality of the information the questionnaire generates.
- TPRM Questionnaire Design Failures: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: specific technical configurations rather than generic policy attestations; evidence documents for claimed control implementations; architecture documentation for critical security domains.
- Training Data Poisoning
-
Training data poisoning is the contamination of a machine learning model's training dataset in ways that cause the model to learn incorrect, biased, or deliberately manipulated patterns , resulting in a model that behaves incorrectly in predictable ways that benefit an attacker or reflect the structural errors in the training corpus.
training data poisoning matters for TPRM because AI products that perform well on vendor-supplied test metrics may still contain systematic blind spots caused by contaminated training data.
- Training Data Poisoning: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: training corpus temporal composition documentation; label quality assessment methodology and results; adversarial blind spot testing results.
- Transfer impact assessment TIA
-
The assessment of whether the destination's law and practice undermine the protection a transfer mechanism promises.
Written per destination it is maintainable; written per vendor it becomes a template with the name changed.
Taught in PRV-280 · See also: Transfer mechanism
- Transfer impact assessments
-
A transfer impact assessment evaluates whether the laws and practices of the destination country, particularly regarding government access to data, undermine the protections that standard contractual clauses are meant to provide. If they do, supplementary measures must be adopted, or the transfer must not proceed. The requirement follows from the Schrems II judgment of 2020.
it is the step most often skipped, because it requires forming a view on another country's surveillance regime, which feels like a job for a lawyer rather than a privacy team. But the clauses require it, regulators ask for it, and a transfer to the United States under SCCs with no TIA on file is a transfer whose mechanism a regulator can set aside.
- Transfer mechanism SCCs, adequacy
-
The legal basis for moving personal data outside a jurisdiction: an adequacy decision, standard contractual clauses, binding corporate rules or a derogation.
Remote access counts as a transfer. Most registers list storage locations only and understate the position substantially.
Taught in PRV-280 · See also: Transfer impact assessment, Processor terms
- Transitive Dependency Risk
-
Transitive dependency risk matters for TPRM because the software vendors whose products you deploy have transitive dependency trees that may contain vulnerable components they are not actively monitoring.
transitive dependency risk matters for TPRM because the software vendors whose products you deploy have transitive dependency trees that may contain vulnerable components they are not actively monitoring.
- Transitive Dependency Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: full transitive SCA scanning confirmation; Log4Shell response timeline as transitive vulnerability case study; a vendor who confirms SCA vulnerability management should be asked about transitive depth coverage. SCA for direct dependencies is a starting point. Full transitive scanning is the complete picture. Log4Shell is the canonical test case for whether the distinction has been operationalised.
- Transparency and Consent Framework TCF
-
An industry standard for passing a user's consent choices through the advertising supply chain, encoded as a consent string.
It is a transport format, not legal cover. A string saying the user consented does not make the consent valid if the banner that produced it was misleading.
Taught in PRV-230 · See also: Consent management platform
- Trust centre
-
The buyer-facing page carrying certifications and their scope, subprocessors, architecture and policy summaries, with sensitive evidence behind a gate.
A well-built one removes a share of questionnaires and shortens the rest. A stale one is a public claim you are visibly not maintaining.
Taught in TRS-201 · See also: Attestation, Answer library
- Trust centres
-
A trust centre is a public page carrying an organization's security and privacy posture: certifications held, reports available under NDA, subprocessor list, policies, and answers to the questions buyers most often ask. Some gate documents behind a request; some publish openly.
it converts repeated one-to-one questionnaire work into self-service, and it signals maturity to a buyer before any conversation has started. A prospect who can see the SOC 2 exists, the subprocessors are listed and the questions are answered is a prospect who arrives at the security review already reassured.
- Trust Services Criteria
-
The Trust Services Criteria are not a list of controls. They are criteria, statements of what must be true, and each organization designs its own controls to meet them. The AICPA states the required outcome; the audited company decides what it does to achieve that outcome; the auditor tests what the company decided.
this is why two companies in the same market can hold SOC 2 reports that read completely differently, with different control counts, different wording and different evidence, and both be valid. It is also why a questionnaire built on one company's controls cannot be answered from another company's report.
- Type I and Type II
-
A Type I report opines on whether controls are suitably designed at a point in time; a Type II adds testing of whether they operated over a period.
A Type I can be achieved by a company that wrote its policies last month. Sophisticated buyers read the Type II exceptions before the opinion.
Taught in TPR-210 · See also: Bridge letter, Complementary user entity control
- Typosquatting in Package Registries
-
Typosquatting matters for TPRM because your vendors' software products are built on dependency trees that may include typosquatted packages without the vendor's knowledge , because the typosquatted package was a transitive dependency, because it had no CVE, and because their SCA scans do not detect malicious packages by definition.
typosquatting matters for TPRM because your vendors' software products are built on dependency trees that may include typosquatted packages without the vendor's knowledge , because the typosquatted package was a transitive dependency, because it had no CVE, and because their SCA scans do not detect malicious packages by definition.
- Typosquatting in Package Registries: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: malicious package detection beyond CVE scanning; dependency pinning and lock file enforcement; a vendor who confirms SCA vulnerability scanning should be asked about malicious package detection. SCA scans known vulnerabilities. Typosquatted packages are not known vulnerabilities , they are malicious code with no CVE. Different tools, different threat model.
V
- Vendor Access Creep Over Time
-
Vendor access creep matters because it creates a systematic divergence between the risk profile the TPRM programme has assessed and the risk profile the vendor relationship actually presents.
vendor access creep matters because it creates a systematic divergence between the risk profile the TPRM programme has assessed and the risk profile the vendor relationship actually presents.
- Vendor Access Creep Over Time: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: current data access scope inventory; access changes since last assessment; confirmation that no undisclosed data access exists.
- Vendor Access via Service Principals
-
A service principal is a non-human identity created in a cloud identity platform , most commonly Azure Active Directory, but the concept exists across all major cloud providers under different names , that represents an application, service, or automated process rather than a person.
service principals are the operational backbone of vendor integrations in Azure and Microsoft 365 environments , and increasingly in AWS and GCP as well, under equivalent constructs like IAM roles for applications and GCP service accounts.
- Vendor Access via Service Principals: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: a specific list of service principals used in your environment with their permission scopes described; a credential rotation policy with a defined maximum validity period , ideally 90 days or less for client secrets; evidence of secure credential storage on the vendor side , a secrets vault, not a configuration file or environment variable.
- Vendor Admin Account Sprawl
-
Admin account sprawl is the accumulation of privileged administrative accounts over time through a combination of legitimate provisioning decisions and insufficient lifecycle management.
admin account sprawl in vendor platforms matters for TPRM because every excess admin account is a high-privilege credential that a threat actor could use to gain full control of the platform.
- Vendor Admin Account Sprawl: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: admin account count with composition , current employees, contractors, external parties; current justification review history , when last reviewed for active need; JIT admin access confirmation or standing account governance documentation.
- Vendor AI Usage Transparency
-
Vendor AI usage transparency is the disclosure and accountability framework for all ways a vendor uses AI that affects the enterprise customer , including both the AI-powered product features that are marketed to the customer and the internal AI systems that use the customer's data for vendor-operational purposes such as customer scoring,
vendor AI usage transparency matters for TPRM because the enterprise's data , its usage patterns, support history, and operational behaviour , may be used by vendor AI systems in ways that affect the service the enterprise receives, the pricing it is offered, and the strategic decisions the vendor makes about the relationship.
- Vendor AI Usage Transparency: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: internal AI system disclosure for enterprise data uses; data processing agreement coverage of internal AI uses; customer classification and routing disclosure.
- Vendor Alert Visibility Gaps
-
Vendor alert visibility gaps are the absence of customer access to the monitoring data, alerts, and detection events generated by a vendor's security operations infrastructure for the systems and data relevant to the customer relationship.
vendor alert visibility gaps matter for TPRM because a vendor's SOC capability assessment tells you what the vendor can detect.
- Vendor Alert Visibility Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: alert escalation procedure for customer-relevant systems; willingness to forward specific alert categories to customer SOC; process for customer to provide detection context to vendor SOC.
- Vendor Analytics Access Risks
-
Analytics access risk arises when the data access granted to analytics teams , the individuals responsible for building dashboards, reports, and analytical models , is significantly broader than what any specific analytical task requires, and is maintained without the access controls, logging, and review cadence applied to other forms of
analytics access risk matters for TPRM because the insider threat scenario most likely to produce a significant customer data breach at a multi-tenant SaaS vendor is not a sophisticated external attack , it is an authorized analytics user who has unrestricted read access to the full customer dataset and chooses to use that access outside
- Vendor Analytics Access Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: analytics access scope documentation , number of analysts, access breadth, customer scope restriction; query-level logging confirmation for analytics sessions; analytics access review history , included in periodic reviews with last review date.
- Vendor Audit Rights Enforcement
-
Vendor audit rights are contractual provisions that permit the customer to conduct, or commission, security assessments of the vendor's environment, controls, and practices.
vendor audit rights enforcement matters for TPRM because independent verification is the governance mechanism that distinguishes risk management from risk documentation.
- Vendor Audit Rights Enforcement: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: technical evidence for specified controls rather than questionnaire responses; cooperation as specified in the right-to-audit clause; confidentiality protection of findings as agreed.
- Vendor Backup Data Risk
-
Backup data contains the same information as production data at the point in time when the backup was made. It has the same sensitivity, the same regulatory classification, and the same breach notification implications if exposed.
vendor backup data risk matters for TPRM because backup systems represent the largest historical data accumulation point in a vendor's environment , they hold copies of customer data going back years, with governance that reflects the state of the organization at each backup's creation time rather than current security standards.
- Vendor Backup Data Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: backup access review history , when last reviewed and what the current access population is; encryption key lifecycle for backups , rotation schedule and historical backup re-encryption policy; backup storage security scan history , most recent scan and any findings.
- Vendor Backup Storage Exposure
-
Vendor backup storage exposure is the risk that arises when a vendor maintains backup copies of customer data under security controls that are weaker, less monitored, and less rigorously governed than the primary production environment that was assessed during vendor due diligence.
backup storage is where data goes to be forgotten , not intentionally, but as a structural consequence of how backup systems are designed and prioritized.
- Vendor Backup Storage Exposure: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: documentation of backup storage location, encryption standard, and access controls matching or exceeding production standards; SOC 2 scope confirmation explicitly addressing backup infrastructure, or an alternative assurance mechanism for backup environments; a defined backup purge process triggered by contract termination with a committed timeline and evidence standard.
- Vendor Breach Detection Delays
-
Vendor breach detection delays are the gap between when a security incident at a vendor environment begins, when the vendor detects it, and when the vendor's customers are notified. These are three distinct timeline events, each of which creates a different category of customer risk.
vendor breach detection delays matter for TPRM because the customer's regulatory obligations, incident response timeline, and risk mitigation options are all directly affected by how quickly the vendor notifies them after a breach is detected.
- Vendor Breach Detection Delays: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: detection-to-notification timeline from past incidents; notification procedure distinguishing preliminary and confirmed notification; commitment to preliminary notification within defined hours of detection.
- Vendor Break-Glass Accounts
-
Break-glass accounts are high-privilege emergency credentials designed for situations where normal access pathways are unavailable and critical systems require immediate intervention , catastrophic lockout events, active incidents requiring admin access faster than normal workflows can provide, and disaster recovery scenarios where standa
break-glass accounts matter for TPRM because vendors who manage customer environments have emergency access mechanisms for those environments , and those mechanisms may be subject to the same drift-to-default problem.
- Vendor Break-Glass Accounts: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: break-glass use log with emergency declaration status for each use; dual authorization technical enforcement confirmation; consequence policy for unauthorized break-glass use.
- Vendor Business Continuity & Resilience
-
Vendor business continuity and resilience matter because operational disruptions at critical vendors directly affect the enterprise's own operations , and the enterprise's ability to maintain service continuity for its own customers during vendor disruptions depends on having accurate information about the vendor's realistic recovery capa
vendor business continuity and resilience matter because operational disruptions at critical vendors directly affect the enterprise's own operations , and the enterprise's ability to maintain service continuity for its own customers during vendor disruptions depends on having accurate information about the vendor's realistic recovery capa
- Vendor Business Continuity & Resilience: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: most recent BCP test results with actual RTO achieved; geographic architecture documentation for primary and backup infrastructure; infrastructure independence confirmation , power and network.
- Vendor Code Review Practices
-
Code review is the practice of having one or more developers examine a code change before it is merged into the main codebase , verifying that it is correct, readable, maintainable, and aligned with the project's standards.
code review sits at the last human checkpoint before code ships , the point in the development process where a security-aware reviewer can catch vulnerabilities that automated tools missed, business logic flaws that scanners cannot detect, and design decisions whose security implications are only visible to someone who understands both th
- Vendor Code Review Practices: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: security review checklist documentation covering authentication, authorization, input handling, and sensitive data for relevant change types; security champion program description , how reviewers are selected, trained, and maintained; developer security training confirmation with platform name, coverage description, and delivery frequency.
- Vendor Compromise Indicators
-
Vendor compromise indicators are the technical evidence , authentication events, network connections, file system changes, registry modifications, and process executions , that demonstrate an attacker's presence in a vendor's environment. Compromise indicators confirm that access occurred.
vendor compromise indicators matter for TPRM because the customer's breach risk assessment , and their regulatory notification decision , depends on understanding not just that a vendor was compromised but what the compromise accomplished for the data the customer shares with that vendor.
- Vendor Compromise Indicators: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: data-level API and query log confirmation; investigation capability to confirm data access consequences; a vendor who confirms compromise detection capability should be asked whether their logging enables consequence confirmation , not just indicator detection. The indicator tells investigators that access occurred. The consequence log tells them what the access was used for.
- Vendor Concentration Risk
-
Vendor concentration risk matters because it is a portfolio property that individual vendor assessments are structurally unable to identify , it requires aggregating data across the vendor portfolio to measure.
vendor concentration risk matters because it is a portfolio property that individual vendor assessments are structurally unable to identify , it requires aggregating data across the vendor portfolio to measure.
- Vendor Concentration Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: vendor's own concentration risk assessment; business continuity plan for largest provider failure; alternative provider readiness for critical functions.
- Vendor Containment Coordination
-
Vendor containment coordination is the challenge of aligning the containment decisions made by a vendor's IR team , who must weigh the operational impact of containment actions across all their customers , with the containment urgency of a specific customer whose data is actively at risk.
vendor containment coordination matters for TPRM because the customer's data loss during an active vendor breach is a direct function of how long the attacker maintains access , and how long the attacker maintains access depends in part on how quickly the vendor executes containment.
- Vendor Containment Coordination: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: containment decision authority and process; maximum containment timeline from customer request; pre-approved containment triggers if available.
- Vendor Control Drift
-
Control drift is the gradual degradation of a vendor's security programme between formal assessment events , the progressive erosion of security posture through personnel turnover, budget reduction, governance attrition, and tool decommission that individually may not meet the threshold for 'material programme change' but collectively rep
control drift matters for TPRM because the security programme quality that justified a vendor's risk rating may no longer accurately describe the vendor's current posture two years into the relationship.
- Vendor Control Drift: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: security team headcount comparison to last assessment; governance meeting frequency in the last six months; a vendor who confirms no material programme changes should be asked the four drift-specific questions. The individual answers may each be below the material change threshold. The combined picture may describe significant drift.
- Vendor Data Access Reviews
-
Access reviews , the periodic process of verifying that all accounts with access to sensitive systems and data should still have that access , are a fundamental identity governance control, required by PCI-DSS, SOC 2, ISO 27001, and most regulatory frameworks that address information security.
access review quality matters for TPRM because it is the control that governs whether the access granted to a vendor's employees remains proportionate to their current roles over time.
- Vendor Data Access Reviews: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: access review revocation rate from most recent cycle; access review data format showing account context provided to reviewers; automated deprovisioning confirmation and HR integration description.
- Vendor Data Aggregation Risks
-
Data aggregation risk is the risk that emerges from the combination of datasets that are individually unremarkable but collectively sensitive.
data aggregation risk matters for TPRM because it represents a category of risk that is invisible at the individual customer assessment level and only visible at the vendor portfolio level.
- Vendor Data Aggregation Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: customer base industry concentration disclosure , how many sector competitors share equivalent data; cross-customer data use restriction confirmation in DPA; technical data isolation architecture description.
- Vendor Data Enrichment Risks
-
Data enrichment is the practice of augmenting a base dataset with additional data attributes sourced from external providers , appending demographic, behavioral, firmographic, and psychographic data points to customer records to create richer profiles.
vendor data enrichment matters for TPRM because it represents a category of data processing that occurs in the vendor's system without the customer's explicit decision to collect or process the enriched data.
- Vendor Data Enrichment Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: enrichment feature disclosure , what is added, from what sources, and what categories; subject access data inventory including enriched categories; DPA enrichment provisions , lawful basis, retention, and deletion obligations for enriched data.
- Vendor Data Handling Agreement Gaps
-
Data handling agreement gaps matter because they determine whether the enterprise's GDPR controller obligations , specifically ensuring that processors only process personal data on documented instructions and for specified purposes , are being met.
data handling agreement gaps matter because they determine whether the enterprise's GDPR controller obligations , specifically ensuring that processors only process personal data on documented instructions and for specified purposes , are being met.
- Vendor Data Handling Agreement Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: clear confirmation that AI training use is prohibited or not practised; policy change advance notification commitment; restricted use confirmation , only for contracted service purpose.
- Vendor Data Lake Exposure
-
A data lake is a centralized repository designed to store large volumes of raw, unprocessed data from multiple sources , application databases, event streams, API logs, external feeds , in its native format, enabling flexible analytical queries without the schema constraints of a traditional relational database.
vendor data lake exposure matters for TPRM because it represents a concentration of sensitive data at a point in the vendor's architecture that is specifically designed to be broadly accessible.
- Vendor Data Lake Exposure: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: data lake existence confirmation with access control description; access review evidence , when data lake access was last reviewed and what the current access population is; ML training data use confirmation and authorization process.
- Vendor Data Retention Practices
-
Vendor data retention matters for TPRM because data held by a vendor beyond the period it is needed represents pure residual risk , risk with no corresponding operational benefit. Data that the vendor no longer needs for any processing purpose is not providing value.
vendor data retention matters for TPRM because data held by a vendor beyond the period it is needed represents pure residual risk , risk with no corresponding operational benefit.
- Vendor Data Retention Practices: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: deletion scope documentation , all systems included in deletion process, with explicit confirmation that backups, dev environments, and sub-processors are covered; backup retention policy , maximum retention periods and whether deletion requests trigger backup purging; technical deletion verification evidence , beyond account manager confirmation, a technically verifiable record of deletion scope.
- Vendor Data Transformation Risks
-
Data transformation is the process by which input data is modified, enriched, derived, or calculated into output data with different characteristics , normalization that standardizes formats, derivation that calculates new attributes from existing ones, enrichment that joins external data with input records, and aggregation that produces
vendor data transformation matters for TPRM because transformation creates new data , data that did not exist before the vendor processed the input , with characteristics that may differ materially from the input data in regulatory status, sensitivity, and rights obligations.
- Vendor Data Transformation Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: derived attribute inventory , what is created from customer input data; DPA derivation provisions , lawful basis and retention for derived attributes; DSAR scope confirmation including derived attributes.
- Vendor Development Environment Security
-
Developer environment security matters for TPRM because the software supply chain begins on developer workstations.
developer environment security matters for TPRM because the software supply chain begins on developer workstations.
- Vendor Development Environment Security: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: developer workstation MDM and endpoint security confirmation; centralised credential management for development credentials; IDE extension policy and monitoring.
- Vendor Directory Integration Risks
-
Directory integration connects two identity systems through a synchronisation relationship , one directory's objects, attributes, and lifecycle events propagate to the other, and in bidirectional integrations, changes flow both ways.
directory integration matters for TPRM because it is one of the highest-trust identity relationships an organization can establish with a vendor , the partner's directory changes propagate directly into the customer's identity infrastructure.
- Vendor Directory Integration Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: directory sync scope documentation , object types and attributes included; inbound sync monitoring confirmation with anomaly alerting; partner admin account security posture for accounts with directory sync access.
- Vendor Escalation Paths
-
Vendor escalation paths are the documented procedures and contact mechanisms that customers use to reach the vendor's security and incident response leadership during a security incident.
vendor escalation paths matter for TPRM because the customer's ability to obtain technical information, coordinate response actions, and influence containment decisions during a vendor breach depends entirely on the effectiveness of the escalation path to the vendor's security leadership.
- Vendor Escalation Paths: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: direct security team contact , named individual with after-hours mobile; expected response time for urgent escalation; active incident protocol for customer escalation.
- Vendor Financial Health as TPRM Signal
-
Financial health monitoring matters because it closes the gap between point-in-time assessment accuracy and current vendor risk reality.
financial health monitoring matters because it closes the gap between point-in-time assessment accuracy and current vendor risk reality.
- Vendor Financial Health as TPRM Signal: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: security team headcount stability confirmation; assessment and certification schedule currency; no deferred security investments of material significance.
- Vendor IAM Roles in Your Cloud
-
An IAM role in a cloud environment is a named set of permissions that defines what actions can be taken on what resources , and critically, it can be assumed by entities that are not human users.
vendor IAM roles are one of the most concrete and direct manifestations of third-party risk in a cloud environment.
- Vendor IAM Roles in Your Cloud: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: a list of the specific IAM roles or service principals the vendor uses in your environment, with permission descriptions; evidence of credential governance on the vendor side , how vendor staff credentials are managed and revoked; a defined decommissioning process that includes explicit steps for surrendering or confirming revocation of cloud access.
- Vendor Identity Audit Evidence
-
Audit evidence for identity governance is the documentation that demonstrates, to an external examiner, that identity governance controls operated as described , not attestations that they exist, but records of their operation.
vendor identity audit evidence matters for TPRM because customers who rely on vendor attestations of identity governance for their own regulatory compliance may find those attestations unsupportable when the regulator asks for underlying evidence.
- Vendor Identity Audit Evidence: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: access review decision record , individual decisions with reviewer and timestamp; role definition document , permission scope for each role; MFA configuration with exception documentation.
- Vendor Identity Compromise Scenarios
-
Vendor identity compromise is the category of attack in which a threat actor gains control of a vendor employee's credentials , or compromises the vendor's identity management infrastructure , and uses those credentials to access customer environments through the vendor's legitimate access pathways.
vendor identity compromise matters for TPRM because it represents the access threat that customer-side security controls are least equipped to detect.
- Vendor Identity Compromise Scenarios: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: behavioural analytics description for support staff customer access; phishing-resistant MFA deployment confirmation for staff with customer access; session recording confirmation for customer environment access.
- Vendor Identity Lifecycle Management
-
Identity lifecycle management is the set of processes that govern the creation, maintenance, and deactivation of user accounts throughout their operational life , ensuring that accounts are created when access is needed, maintained proportionately as needs change, and deactivated when access is no longer needed.
vendor identity lifecycle matters for TPRM because platform accounts belonging to former vendor employees represent a specific and well-documented credential compromise risk.
- Vendor Identity Lifecycle Management: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: departure notification process documentation , platform offboarding included in employee offboarding checklist; current employment verification for all active platform accounts; last roster reconciliation date and findings.
- Vendor Identity Monitoring
-
Identity monitoring at the vendor boundary encompasses two distinct but complementary monitoring domains. Customer-side monitoring captures what vendor identities do within the customer environment , access events, data queries, configuration changes, session duration, and access patterns that deviate from baseline.
vendor identity monitoring matters for TPRM because the detection capability for vendor identity compromise must span the vendor-customer boundary , customer monitoring alone cannot detect the pre-session attack chain, and vendor monitoring alone may not act on signals before customer environments are reached.
- Vendor Identity Monitoring: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: vendor-side identity monitoring capability , failed authentication alerting and priority thresholds; identity security notification obligation and timeline; a vendor whose monitoring detects sixty-three failed authentication attempts against a staff member but does not generate a priority alert and does not notify the customer has monitoring that captures the signal without acting on it. Both halves matter: the signal and the response. Ask about both.
- Vendor Identity Risk Scoring
-
Identity risk scoring is the practice of calculating a composite risk level for individual identity principals , user accounts, service accounts, and API credentials , based on multiple signals that affect the probability and impact of their compromise.
vendor identity risk scoring matters for TPRM because vendor staff who access customer environments represent a concentrated risk surface where a single individual's compromise can have multi-customer impact.
- Vendor Identity Risk Scoring: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: identity risk scoring description , signals used and scoring methodology; enhanced controls for individuals above risk thresholds; a vendor who responds with 'all staff go through our standard security program' has described program-level governance. Ask specifically whether any individual in their team has been identified as elevated risk based on the combination of their access scope and their individual security posture signals. The standard program establishes the floor. Risk scoring identifies who is above it.
- Vendor Incident Notification Failures
-
Incident notification matters because the enterprise's ability to respond to a vendor breach depends directly on when and how completely it is informed. Delayed or incomplete notification means delayed response, delayed regulatory compliance, delayed individual notification, and extended exposure to the breach's consequences.
incident notification matters because the enterprise's ability to respond to a vendor breach depends directly on when and how completely it is informed.
- Vendor Incident Notification Failures: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: written confirmation of notification trigger and timeline interpretation; direct security team contact for breach notification; notification content template or minimum content commitment.
- Vendor Inventory Completeness
-
Vendor inventory completeness is the degree to which an organization's TPRM programme has identified and accounted for all active third-party relationships , not just the vendors that were intentionally added to the risk management programme, but the full population of vendors that have access to the organization's data, systems, or opera
vendor inventory completeness is the foundational requirement of TPRM , a programme that does not know what it does not know cannot manage the risk it has not identified.
- Vendor Inventory Completeness: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: intake trigger implementation across procurement pathways; inventory completeness ratio reported to leadership; a vendor who confirms a mature TPRM programme should be asked how they know their inventory is complete. Process maturity is about the vendors the programme knows. Inventory completeness is about whether the programme knows all the vendors it should.
- Vendor IR Plan Maturity
-
IR plan maturity is the degree to which an incident response plan reflects a genuine, tested operational capability , not just the existence of documentation that describes intended procedures.
vendor IR plan maturity matters for TPRM because the customer's outcome in a vendor breach depends on the quality of the vendor's IR execution , and execution quality depends on maturity that documentation alone cannot demonstrate.
- Vendor IR Plan Maturity: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: most recent exercise date and scenario; scenario-specific playbook availability , ransomware, data exfiltration; IR performance metrics from exercises , MTTD, MTTC.
- Vendor IR Testing Frequency
-
Vendor IR testing frequency encompasses not just how often exercises occur, but how broadly they cover the attack scenarios, technology environments, and organizational participants that a real incident would involve. Testing frequency is a necessary but insufficient indicator of IR programme effectiveness.
vendor IR testing frequency matters for TPRM because the IR capability that matters most , the coordinated response involving legal, communications, operations, and security working together under incident pressure , is only built through exercises that practice exactly that coordination.
- Vendor IR Testing Frequency: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: exercise log , dates, scenarios, participants; a vendor who confirms regular IR testing should be asked for the exercise log. The log reveals what the confirmation does not: frequency specificity, scenario diversity, participant coverage, and red team scope. The exercise log is the evidence. The confirmation is the description.
- Vendor management under CC9
-
CC9 requires the organization to identify and mitigate risks from business disruption and from vendors and business partners. In practice, the vendor half requires that you know who your vendors are, assess the risk they carry, monitor them over the relationship, and manage their termination.
this is the criterion that makes your own third-party risk programme auditable. It is also why a vendor asking you for a SOC 2 will, in the same conversation, ask how you assess your vendors. The two questions are the same criterion viewed from each side.
- Vendor Monitoring Coverage
-
Vendor monitoring coverage, from the customer's perspective, is the extent to which the customer has visibility into security events in the vendor's environment that are relevant to the customer's risk , specifically events that might indicate a supply chain attack in progress, that might predict threats that will emerge in the customer's
vendor monitoring coverage matters for TPRM because it determines how early in the supply chain attack lifecycle the customer can detect an attack originating in the vendor's environment.
- Vendor Monitoring Coverage: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: developer credential compromise alert procedure; supply chain event forwarding commitment; a software vendor whose product is deployed into the customer's environment should be asked whether their build pipeline is monitored and whether credential compromises in that environment would be forwarded to the customer. The vendor monitoring covers the vendor. The forwarding agreement covers the customer.
- Vendor offboarding
-
Offboarding is what happens when a vendor relationship ends: access is revoked, data is returned or destroyed with evidence, integrations and API keys are disabled, the contract is closed out and the register entry is marked with a date. It is the stage of the lifecycle that most reliably gets skipped, because relationships usually end quietly and nobody owns the moment.
the end of a relationship is where data is left behind. A former vendor still holds a copy, still has a service account in your directory, still has a webhook pointing at your systems, and nobody notices until an audit samples exited vendors or a breach at that vendor exposes data you thought had been destroyed two years earlier.
- Vendor Offboarding Risk
-
Vendor offboarding risk matters because orphaned access and retained data represent ongoing exposure that generates no business value. The API key that persisted after contract closure is a credential that can be used by an attacker who obtains it , either through the former vendor's systems or through the former employee's devices.
vendor offboarding risk matters because orphaned access and retained data represent ongoing exposure that generates no business value.
- Vendor Offboarding Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: data return and deletion process and timeline; certified deletion capability with audit evidence; data inventory at end of engagement.
- Vendor Onboarding Security Gates
-
Vendor onboarding security gates matter because the risk a vendor represents does not wait for the assessment to be completed , it is present from the moment access is provisioned. An unassessed vendor with production data access represents the same risk as an assessed vendor with identified control weaknesses.
vendor onboarding security gates matter because the risk a vendor represents does not wait for the assessment to be completed , it is present from the moment access is provisioned.
- Vendor Onboarding Security Gates: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: onboarding workflow with TPRM clearance checkpoint; gate compliance ratio as programme metric; a vendor who confirms TPRM programme maturity should be asked whether their own vendor assessments are completed before access is provisioned. The gate's value is entirely in its timing. Post-access assessment is not a gate , it is a retrospective review.
- Vendor Onboarding/Offboarding Delays
-
Vendor access onboarding and offboarding delays are the timing gaps between when access should be created or removed and when it actually is.
onboarding and offboarding timing risks matter for TPRM because they represent the practical failure modes of access governance processes that are correct in design but miscalibrated in execution.
- Vendor Onboarding/Offboarding Delays: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: departure notification SLA , maximum time from departure to customer notification; offboarding timing confirmation , event-triggered vs scheduled removal; onboarding completion time data , average and maximum from nomination to access.
- Vendor Open Source Contribution Risk
-
Open-source contribution risk matters for TPRM because the open-source libraries that vendor software is built on are maintained by human contributors whose motivations are subject to change , and because the trust model that makes open-source development efficient is also the trust model that supply chain attackers specifically target.
open-source contribution risk matters for TPRM because the open-source libraries that vendor software is built on are maintained by human contributors whose motivations are subject to change , and because the trust model that makes open-source development efficient is also the trust model that supply chain attackers specifically target.
- Vendor Open Source Contribution Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: XZ Utils-style attack awareness in supply chain security model; a vendor who confirms open-source dependency management should be asked about contributor risk monitoring. Dependency version management covers what package is used. Contributor monitoring covers who is trusted to modify that package.
- Vendor Passwordless Adoption Risks
-
Passwordless authentication replaces the shared secret (password) with a cryptographic credential , a passkey, hardware security key, or certificate , that proves identity through a private key that never leaves the authenticating device.
passwordless adoption risks matter for TPRM because passwordless announcements are increasingly used as evidence of advanced authentication security in vendor assessments , and the gap between deployment announcement and complete migration is rarely disclosed.
- Vendor Passwordless Adoption Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: passwordless coverage percentage , total authentication events vs migrated; infrastructure pathway migration status , VPN, SSH, database; migration roadmap for remaining pathways with timeline.
- Vendor Patch Cadence Reality
-
Patch cadence reality matters because the software your enterprise deploys continues to accumulate vulnerability risk between your initial assessment and your next planned vendor review. A vendor who patches slowly or incompletely is a vendor whose software becomes progressively more vulnerable over time.
patch cadence reality matters because the software your enterprise deploys continues to accumulate vulnerability risk between your initial assessment and your next planned vendor review.
- Vendor Patch Cadence Reality: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: historical patch timeline data , CVE publication vs patch release; list of unpatched critical CVEs with remediation timeline; average patch cadence by severity.
- Vendor Patch SLAs vs Reality
-
Patch velocity is the operational metric that determines how long your organization's data is exposed through known vulnerabilities in vendor applications. It is not a theoretical risk indicator , it is a calendar calculation.
patch velocity is the operational metric that determines how long your organization's data is exposed through known vulnerabilities in vendor applications.
- Vendor Patch SLAs vs Reality: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: actual time-to-patch data for the last four to six critical CVEs affecting the vendor's application , specific numbers, not policy statements; customer notification process documentation for critical CVEs , timeline, channel, and interim guidance commitment; exception process documentation with frequency data , how often SLA exceptions are granted and the transparency provided to customers when they are.
- Vendor privacy assessments
-
A vendor privacy assessment asks what personal data the vendor will process, for what purpose, under what lawful basis, where it will go, for how long it will be kept, who else will touch it, and what happens to it when the relationship ends. It is a different set of questions from a security assessment, and a vendor can pass one comprehensively while failing the other.
security questionnaires cover controls and skip purpose entirely. A perfectly secure vendor using customer data for its own model training, retaining it indefinitely, and transferring it to three countries without a mechanism would pass a security review without a single finding.
- Vendor Reassessment Frequency
-
Vendor reassessment frequency is the cadence at which a vendor relationship receives a formal security assessment , the periodic deep-dive that confirms the vendor's security posture, identifies control changes, and updates the risk rating for the relationship.
vendor reassessment frequency matters for TPRM because the frequency of formal assessment should reflect the current risk profile of the relationship , which changes as the vendor and the relationship evolve.
- Vendor Reassessment Frequency: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: current data processing volume compared to last assessment date; security incidents affecting other customers since last assessment; material infrastructure changes , new cloud regions, new system integrations.
- Vendor Reporting Data Leaks
-
Vendor reporting , the delivery of analytical reports, dashboards, data exports, and business intelligence summaries to customers or internal stakeholders , is a data transfer activity that is frequently not governed with the same rigor as other forms of data access. Reports contain data.
vendor reporting data leaks matter for TPRM because reporting is one of the highest-volume ongoing data flows in most vendor relationships , weekly or monthly transfers of customer data to external recipients , and it is almost never assessed with the rigor applied to other data transfers of equivalent volume and sensitivity.
- Vendor Reporting Data Leaks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: report content confirmation , aggregate only or underlying records accessible; distribution list review history with current recipient authorization confirmation; delivery mechanism description , encrypted or plaintext.
- Vendor Resilience Testing and Tabletop Exercises
-
Vendor resilience testing matters because the enterprise's actual resilience to vendor disruption is determined by whether its contingency plans are executable , not by whether they exist. A well-documented BCP that cannot be executed under the disruption scenario it describes provides false assurance.
vendor resilience testing matters because the enterprise's actual resilience to vendor disruption is determined by whether its contingency plans are executable , not by whether they exist.
- Vendor Resilience Testing and Tabletop Exercises: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: most recent tabletop exercise records for vendor disruption scenarios; tested recovery time versus designed RTO; BCP updates driven by exercise findings.
- Vendor Response Validation
-
Vendor response validation is the customer's process for independently verifying that a vendor's incident response has achieved complete and durable remediation , not just eradication of identified threats, but confidence that no residual attacker presence remains in the vendor's environment.
vendor response validation matters for TPRM because the customer's resumed data sharing with a vendor following a remediation report re-exposes their data to any residual attacker presence the remediation did not eradicate.
- Vendor Response Validation: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: IOC sharing commitment , investigation IOCs provided to customer; enhanced monitoring metrics during monitoring period; willingness to commission independent validation for significant breaches.
- Vendor Risk Aggregation
-
Vendor risk aggregation is the analysis of portfolio-level risk exposures that emerge from the combination of individually-assessed vendor relationships , specifically, the correlated risks created by shared infrastructure dependencies, shared data access, and shared operational pathways that make multiple individually-low-risk vendors be
vendor risk aggregation matters for TPRM because boards and regulators increasingly expect organizations to understand their aggregate risk exposure from vendor relationships , not just the distribution of individual risk scores, but the concentration risks that shared dependencies create.
- Vendor Risk Aggregation: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: primary cloud infrastructure provider disclosure; business continuity plan for infrastructure provider availability events; alternative infrastructure or failover capability.
- Vendor Risk Appetite Alignment
-
Risk appetite alignment matters because risk acceptances that violate the enterprise's stated risk appetite create a gap between the risk posture the board and senior leadership believe the enterprise has accepted and the risk posture that operational decisions have actually created.
risk appetite alignment matters because risk acceptances that violate the enterprise's stated risk appetite create a gap between the risk posture the board and senior leadership believe the enterprise has accepted and the risk posture that operational decisions have actually created.
- Vendor Risk Appetite Alignment: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: confirmation of minimum control implementation; timeline for any unimplemented minimums; no cost-barrier acceptance of basic security requirements.
- Vendor Risk Register Accuracy
-
Risk register accuracy matters because leadership risk decisions , where to direct remediation resources, which vendors to escalate to the board, which relationships to review , are made from register data. An inaccurate register produces inaccurate risk prioritisation.
risk register accuracy matters because leadership risk decisions , where to direct remediation resources, which vendors to escalate to the board, which relationships to review , are made from register data.
- Vendor Risk Register Accuracy: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: register update process and trigger documentation; a vendor who confirms a comprehensive risk register should be asked how it is kept current. The register's value is its accuracy. The update process is the mechanism that maintains accuracy between formal reviews.
- Vendor Security Disclosure Programmes
-
Vendor security disclosure programmes matter for TPRM because they determine how quickly vulnerabilities in vendor software are discovered, remediated, and communicated to customers.
vendor security disclosure programmes matter for TPRM because they determine how quickly vulnerabilities in vendor software are discovered, remediated, and communicated to customers.
- Vendor Security Disclosure Programmes: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: patch timeline adherence data for critical disclosures; advance customer notification process and timeline; disclosure programme scope and contact information.
- Vendor Security Questionnaire Fatigue
-
Questionnaire fatigue matters because it undermines the intelligence quality that questionnaires are supposed to generate. Vendors who are completing large volumes of customer questionnaires are responding in ways that minimise their completion time rather than ways that provide genuine security insight.
questionnaire fatigue matters because it undermines the intelligence quality that questionnaires are supposed to generate.
- Vendor Security Questionnaire Fatigue: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: completed standardised questionnaire framework (SIG, CAIQ) if available; SOC 2 report for relevant control domains; vendor security profile on standardised platform if maintained.
- Vendor Security Testing Scope Gaps
-
Security testing scope gaps are the portions of an application's attack surface that are excluded from security testing , either through deliberate scope limitation decisions, through failure to update scope as the application evolves, or through implicit exclusion of components that were never considered for inclusion.
security testing scope gaps are the most fundamental validity problem in vendor application security assessment , more fundamental than testing methodology, tester skill, or finding remediation.
- Vendor Security Testing Scope Gaps: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: penetration test scope documentation , the actual scope definition, not the executive summary; explicit confirmation that customer integration components are included in tested scope; full API surface inventory with scope coverage mapping , which APIs are tested and which are not.
- Vendor SOC Integration
-
Vendor SOC integration is the operational coordination between a vendor's and a customer's security operations teams , specifically the mechanisms for real-time communication during shared incidents, for escalating detections relevant to the other party's environment, and for correlating events across both environments to identify attacks
vendor SOC integration matters for TPRM because sophisticated supply chain attackers understand and exploit the investigative gaps between independent security operations teams.
- Vendor SOC Integration: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: a vendor with a mature SOC should be asked what triggers a direct call to the customer's SOC rather than completing an internal investigation first. The SOC maturity is the capability. The escalation trigger and the direct contact are the integration.
- Vendor SSO Integration Risks
-
Single Sign-On is an authentication federation mechanism , it enables users to authenticate to multiple systems using a single set of credentials managed by a central identity provider.
vendor SSO integration risks matter for TPRM because SSO is increasingly presented as a security control in vendor assessments , confirming SSO integration as evidence that access is centrally governed.
- Vendor SSO Integration Risks: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: authentication scoping documentation , groups or criteria restricting authentication; SAML attribute mapping for role determination , attributes used and role assignment logic; default access tier for authenticated users without role attributes , confirms fallback behavior.
- Vendor Telemetry Limitations
-
Telemetry limitations are the gaps in the volume, detail, and coverage of security-relevant data that a vendor's monitoring infrastructure has access to , gaps that constrain what the SIEM can detect regardless of how mature the detection rules and SOC operations are.
vendor telemetry limitations matter for TPRM because they create attack path visibility gaps that are invisible to the vendor's SOC and to the customer's TPRM assessment.
- Vendor Telemetry Limitations: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: logging level by source system for attack-path-relevant systems; SIEM integration status for each source; a vendor who confirms comprehensive SIEM coverage should be asked for the telemetry inventory for the specific systems on the attack path to customer data. SIEM coverage describes what is connected. Telemetry quality describes what that connection provides.
- Vendor Threat Visibility
-
Vendor threat visibility is the customer's ability to see security-relevant activity in the vendor's environment that is directly relevant to the security of the customer's data and integration , specifically the activity that, combined with the customer's own monitoring data, would reveal a cross-boundary attack that neither party's moni
vendor threat visibility matters for TPRM because the most sophisticated supply chain attacks deliberately target the seams between monitoring environments , using the integration between vendor and customer as both an attack pathway and a detection evasion technique.
- Vendor Threat Visibility: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: integration monitoring data sharing willingness; API activity metrics available for sharing; integration anomaly alert sharing protocol.
- Vendor tiering
-
Tiering sorts vendors by the harm they could do, so that assessment effort follows exposure rather than being spread evenly across a list where most entries could not hurt you. Two or three tiers, defined by objective tests: does the vendor hold personal or confidential data, do they have access into your environment, and are they in the critical path of something customers rely on.
a programme that assesses four hundred vendors to the same depth assesses none of them well. Tiering is the mechanism that lets you spend four hours on the support tool that holds ticket attachments full of personal data and ten minutes on the plant supplier, without anyone having to argue about it each time.
- Vendor Tiering Inaccuracies
-
Vendor tiering is the process of categorising vendor relationships by risk level to apply proportionate assessment depth, monitoring intensity, and governance requirements.
vendor tiering inaccuracies matter for TPRM because the entire programme's risk management structure depends on tiers being accurate.
- Vendor Tiering Inaccuracies: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: complete description of all services and integrations provided by the vendor entity and related subsidiaries; disclosure of any acquisitions that have affected the relationship; IT integration inventory cross-reference confirmation.
- Vendor-Managed Encryption Keys
-
Encryption key management is the discipline of controlling who can generate, access, use, rotate, and revoke the cryptographic keys that protect data. Encryption without key management is like locking a safe and leaving the combination written on top of it , the mechanism is sound but the control is absent.
in the context of third-party risk, encryption key governance determines whether encryption is a meaningful control or a compliance checkbox.
- Vendor-Managed Encryption Keys: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: a clear description of the key management model , not 'we use encryption' but the specific model and who controls the keys; a defined key revocation process tied to contract termination with a specific timeframe; key usage audit log availability , evidence that decryption operations are logged and reviewable.
- VEX , Vulnerability Exploitability eXchange
-
VEX matters for TPRM because without it, enterprises either triage large vulnerability lists manually , an expensive and slow process , or apply blanket risk acceptance to unflagged vulnerabilities that may or may not be exploitable.
VEX matters for TPRM because without it, enterprises either triage large vulnerability lists manually , an expensive and slow process , or apply blanket risk acceptance to unflagged vulnerabilities that may or may not be exploitable.
- VEX , Vulnerability Exploitability eXchange: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: VEX document in OpenVEX or CycloneDX VEX format; justifications for Not Affected dispositions; affected disposition list with remediation timeline.
- VPN vs Zero Trust Network Access
-
VPN versus ZTNA matters for TPRM because VPN access confirmation provides assurance for encrypted transport and authentication without addressing the scope of network access that the VPN provides.
VPN versus ZTNA matters for TPRM because VPN access confirmation provides assurance for encrypted transport and authentication without addressing the scope of network access that the VPN provides.
- VPN vs Zero Trust Network Access: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: VPN access scope , network ranges vs actual requirements; user count in VPN groups vs legitimate access requirements; ZTNA adoption or roadmap for vendor access.
- Vulnerability exploitability exchange VEX
-
A statement giving, per vulnerability and product, whether it is affected, not affected, fixed or under investigation, with a justification.
One line of VEX answers the fourteen customer tickets a single publicised vulnerability would otherwise generate.
Taught in CYB-201 · See also: Software bill of materials, Vulnerability management
- Vulnerability management
-
The programme that finds, prioritises, fixes and evidences the closure of weaknesses across the estate.
Coverage comes before volume and exposure before severity: a seven-day target is credible when the queue holds a dozen items, not ninety.
Taught in CYB-220 · See also: Software bill of materials, Threat intelligence
- Vulnerability management SLAs
-
A remediation SLA attaches a window to each priority band: internet-facing with known exploitation, seven days; everything else with a fix available, thirty; systems awaiting decommissioning tracked separately with a date. The bands are defined by exposure, exploitability and asset value, with the scanner's severity score as an input rather than as the answer.
an SLA missed every month teaches everyone to ignore SLAs. A company whose scanner produced ninety criticals a month against a seven-day window missed it consistently, which made the metric meaningless. Re-prioritising by internet exposure and known exploitation left about a dozen items a month in the seven-day band, which was achievable, and the SLA became real.
W
- Web App Firewall Reliance Myths
-
WAF presence is one of the most frequently cited application security controls in vendor questionnaire responses , it is visible, it is measurable (blocks per day, attacks mitigated), and it provides impressive-sounding metrics that suggest active security engagement.
WAF presence is one of the most frequently cited application security controls in vendor questionnaire responses , it is visible, it is measurable (blocks per day, attacks mitigated), and it provides impressive-sounding metrics that suggest active security engagement.
- Web App Firewall Reliance Myths: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: compensating control tracking confirmation , WAF-covered vulnerabilities tracked separately from patched ones with defined review timelines; WAF blocking mode confirmation with application surface coverage scope; false positive management process , confirming rules have not been systematically disabled to reduce operational friction.
- What DevSecOps Actually Means vs What Vendors Say It Means
-
DevSecOps: Confirmed. Security Scans: Running.
the DevSecOps gap matters for TPRM because confirming that a vendor runs DevSecOps tools without assessing whether those tools enforce anything provides security assurance for security theatre rather than security practice.
- What DevSecOps Actually Means vs What Vendors Say It Means: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: enforcement policy for security scan failures , what blocks deployment; coverage map for security scanning , frameworks, ecosystems, image layers; finding remediation workflow with ownership and SLA.
- What Is SLSA and Why Your Vendors Should Care
-
SLSA Compliant: Confirmed. SLSA Level: 1.
SLSA matters for TPRM because software supply chain attacks , specifically the compromise of build pipelines and artifact distribution , are among the most impactful and most difficult to detect attack vectors currently being exploited.
- What Is SLSA and Why Your Vendors Should Care: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: specific SLSA level , not binary compliance; provenance attestation for a recent release; verification method for the attestation.
- Wireless Network Security and Vendor Risk
-
Wireless network security matters for TPRM because it determines the physical perimeter of the network , how close an attacker needs to be to access any part of the network.
wireless network security matters for TPRM because it determines the physical perimeter of the network , how close an attacker needs to be to access any part of the network.
- Wireless Network Security and Vendor Risk: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: corporate wireless authentication method , 802.1X or shared; guest credential rotation schedule and last rotation date; guest portal implementation if applicable.
Z
- Zero Trust Architecture , What It Actually Means
-
Zero Trust architecture matters for TPRM because vendors who confirm Zero Trust without the network segmentation dimension have a flat network that maximises lateral movement potential for any attacker who compromises any internal user or system.
zero Trust architecture matters for TPRM because vendors who confirm Zero Trust without the network segmentation dimension have a flat network that maximises lateral movement potential for any attacker who compromises any internal user or system.
- Zero Trust Architecture , What It Actually Means: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: network segmentation description , which zones are isolated from which; ZTNA or equivalent network access control implementation; device posture verification at access time.
- Zero Trust for Software Supply Chains
-
Zero Trust for software supply chains matters for TPRM because the security improvements that Zero Trust provides in network contexts apply equally to the software supply chain , and enterprises that have invested in Zero Trust network architecture while leaving their software supply chains on implicit trust have created an asymmetry wher
zero Trust for software supply chains matters for TPRM because the security improvements that Zero Trust provides in network contexts apply equally to the software supply chain , and enterprises that have invested in Zero Trust network architecture while leaving their software supply chains on implicit trust have created an asymmetry wher
- Zero Trust for Software Supply Chains: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: publisher identity verification beyond registry presence; build agent step-level credential minimisation; zero Trust supply chain architecture description.
- Zero Trust Maturity Model for TPRM Assessment
-
Zero Trust maturity assessment matters for TPRM because the security value of a vendor's Zero Trust programme is determined by their actual implementation depth across all five dimensions , not by the label they apply to it.
zero Trust maturity assessment matters for TPRM because the security value of a vendor's Zero Trust programme is determined by their actual implementation depth across all five dimensions , not by the label they apply to it.
- Zero Trust Maturity Model for TPRM Assessment: the evidence
-
When you ask a vendor about this, these are the artefacts worth asking for rather than assurances: evidence for each claimed maturity stage; current vs target stage by pillar; a vendor who confirms Zero Trust should be asked for pillar-level maturity ratings. Zero Trust confirmed describes the label. Pillar-level maturity with evidence describes the implementation depth. Both are needed to compare vendor Zero Trust programmes.
Maintained by the association. A term here is a summary; the course named beside it is where the practice is taught.