Search every question across sub-FAQs

Start with the operational decision: define what Assurance Evidence means in your ISO/IEC 27036 scope, who owns it, and what record proves the decision is current.

For ISO/IEC 27036, the useful record is practical: decision, scope, owner, evidence, exception, review trigger, and next action. This keeps the answer useful in audits, customer reviews, incidents, supplier reviews, and management review.

The evidence should show the process operating. For this artifact, the strongest record usually includes supplier tiering, due diligence, contract clauses, assurance reviews, fourth-party visibility, incident handoffs, monitoring records, and offboarding evidence.

Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, AI system, service, incident, risk, or control sample behind the answer.

The person who can fund, operate, and correct the process should own the decision; governance should review consistency and exceptions.

For high-impact changes, approval should include the teams affected by the evidence: security, privacy, resilience, supplier management, AI governance, legal, risk, or business service owners as relevant.

Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, AI system, personal data flow, incident process, or customer commitment changes.

A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.

Start with the operational decision: define what Cloud Suppliers means in your ISO/IEC 27036 scope, who owns it, and what record proves the decision is current.

For cloud security work, write the provider/customer split before requesting evidence; the same control can be provider-owned, customer-owned, or shared depending on the service model and contract. This keeps the answer useful in audits, customer reviews, incidents, supplier reviews, and management review.

The evidence should show the process operating. For this artifact, the strongest record usually includes supplier tiering, due diligence, contract clauses, assurance reviews, fourth-party visibility, incident handoffs, monitoring records, and offboarding evidence.

Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, AI system, service, incident, risk, or control sample behind the answer.

The person who can fund, operate, and correct the process should own the decision; governance should review consistency and exceptions.

For high-impact changes, approval should include the teams affected by the evidence: security, privacy, resilience, supplier management, AI governance, legal, risk, or business service owners as relevant.

Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, AI system, personal data flow, incident process, or customer commitment changes.

A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.

Start with the operational decision: define what Contract Controls means in your ISO/IEC 27036 scope, who owns it, and what record proves the decision is current.

For supplier work, keep the supplier relationship type, tier, contract control, fourth-party exposure, monitoring cadence, incident notice route, and exit evidence in one record. This keeps the answer useful in audits, customer reviews, incidents, supplier reviews, and management review.

The evidence should show the process operating. For this artifact, the strongest record usually includes supplier tiering, due diligence, contract clauses, assurance reviews, fourth-party visibility, incident handoffs, monitoring records, and offboarding evidence.

Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, AI system, service, incident, risk, or control sample behind the answer.

The person who can fund, operate, and correct the process should own the decision; governance should review consistency and exceptions.

For high-impact changes, approval should include the teams affected by the evidence: security, privacy, resilience, supplier management, AI governance, legal, risk, or business service owners as relevant.

Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, AI system, personal data flow, incident process, or customer commitment changes.

A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.

Start with the operational decision: define what Fourth Parties means in your ISO/IEC 27036 scope, who owns it, and what record proves the decision is current.

For supplier work, keep the supplier relationship type, tier, contract control, fourth-party exposure, monitoring cadence, incident notice route, and exit evidence in one record. This keeps the answer useful in audits, customer reviews, incidents, supplier reviews, and management review.

The evidence should show the process operating. For this artifact, the strongest record usually includes supplier tiering, due diligence, contract clauses, assurance reviews, fourth-party visibility, incident handoffs, monitoring records, and offboarding evidence.

Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, AI system, service, incident, risk, or control sample behind the answer.

In this context, suppliers are the direct parties you acquire from, while fourth parties are the downstream suppliers and supply chains behind those suppliers. NIST SP 800-161 describes cybersecurity risks throughout the supply chain as arising from suppliers, their supply chains, and their products or services, and it also notes that supplier contracts should flow down to sub-tier contractors.

That distinction matters because a direct supplier may look low risk while a sub-tier provider, shared component, or outsourced process creates the real exposure. Manage both the direct relationship and the downstream dependency in the same record.

Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, AI system, personal data flow, incident process, or customer commitment changes.

A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.

Start with the operational decision: define what Risk Tiers means in your ISO/IEC 27036 scope, who owns it, and what record proves the decision is current. Under NIST SP 800-30, risk is typically a function of likelihood and impact, so a practical tiering model should sort suppliers, services, or scenarios by those two factors and by the business context that makes them more or less important.

For risk work, separate the model from the result: risk criteria, scenario assumptions, likelihood rationale, impact rationale, existing controls, treatment choice, residual risk, and acceptance authority. This keeps the answer useful in audits, customer reviews, incidents, supplier reviews, and management review. Use a lower tier for low-likelihood, low-impact, well-controlled relationships; use a higher tier when the supplier, service, data flow, or dependency can create greater business impact, wider exposure, or more difficult recovery.

The evidence should show the process operating. For this artifact, the strongest record usually includes supplier tiering, due diligence, contract clauses, assurance reviews, fourth-party visibility, incident handoffs, monitoring records, and offboarding evidence.

Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, AI system, service, incident, risk, or control sample behind the answer.

The person who can fund, operate, and correct the process should own the decision; governance should review consistency and exceptions.

For high-impact changes, approval should include the teams affected by the evidence: security, privacy, resilience, supplier management, AI governance, legal, risk, or business service owners as relevant.

Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, AI system, personal data flow, incident process, or customer commitment changes.

A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.