# Cloud and SaaS review

Test shared responsibility against actual settings, data paths and recovery evidence.

SecNet.Work | 2026.10 | 2026-10-21

Provider security capabilities and customer configuration are different. Review tenant boundaries, administrative identities, external sharing, log coverage and recovery together. Controls may require particular licences or service tiers; verify the product and contract rather than assuming availability.

## Work boundary
IaaS, PaaS and SaaS; responsibilities vary by service. All example data is fictional.

## Process

### 1. Allocate responsibility
Record provider/customer responsibilities for data, identity, infrastructure and application. Explain “provider-managed” by service layer and assign any gaps.

Expected evidence: Service-specific responsibility matrix

### 2. Inspect effective settings
Compare policy templates with actual resource settings. Sample privileged accounts, emergency access, guests and sharing links. Check exceptions and excluded resources even when a policy is assigned.

Expected evidence: Resource scope and effective configuration

### 3. Test logging and recovery
Generate an authorized test event and observe destination and latency. Review retention, clock and access. Validate backup or retention capabilities with an independent restore test.

Expected evidence: Test-event trail and restore result

### 4. Monitor drift
Define how coverage survives new resources and licence changes. Record the owner, retest date and exceptions; do not interpret a green dashboard as proof that the entire tenant is secure.

Expected evidence: Drift action and scoped retest

## One control, three perspectives

### Operator
Which setting is actually effective?
Run an authorized resource-level negative test.
Evidence: Effective configuration and test result

### Auditor
Are resources excluded?
Reconcile inventory and policy scope.
Evidence: Coverage and exceptions

### Leader
Can we exit the service?
Verify restore and portability with the owner.
Evidence: Recovery criteria and trial

## Evaluate evidence

**Claim:** External sharing is restricted.

**Weak support:** The policy name includes “secure”.

**Stronger support:** Effective resource settings, an external-guest test and exceptions were verified in one snapshot.

**Rationale:** An assigned policy may not apply because of exclusions or legacy resources.

## Decision desk
A central policy is enabled, but a project can create anonymous links.
Start: start

### start
How do you proceed?

- **Investigate effective scope and exceptions** (good)
  You inspect resource behavior rather than a central claim. Test the correction’s coverage next.
  Next: verify

- **Close because the central panel is green** (risk)
  The panel does not explain excluded-project behavior. Scope and actual-access evidence are required.
  Next: repair

- **Close without a rationale** (incomplete)
  Deferring an open issue is not closure evidence. Record the uncertainty, owner and next verification step.
  Next: revise

### verify
New links are blocked, but old anonymous links still work.

- **Include existing links and retest** (good)
  A future-facing setting may not revoke existing shares. A scoped correction is planned.
  Next: planned

- **Accept the claim without testing** (risk)
  The initial claim and observed result differ. Support closure with a repeatable check in the same scope, rather than a promise or ticket status.
  Next: revise

### repair
External sharing is discovered later.

- **Involve the data owner and inspect link/access records** (good)
  Validate impact and scope with evidence. Authorized teams separately assess notification needs.
  Next: planned

- **Delete the earlier record and close** (risk)
  Deleting the earlier decision undermines learning and accountability. Link the new action to the prior record and keep the rationale and residual risk visible.
  Next: revise

### supported
This decision is supported by the evidence in the example. Verify closure conditions in your own scope.

### revise
The decision lacks support. Record the rationale and required evidence, then reassess.

### planned
A remediation path is defined. Keep the matter open until implementation and verification are complete.

## Worked example
Entirely fictional.
- Resource: Example project
- Owner: Cloud service owner
- Expected control: No anonymous sharing
- Effective setting: Legacy-link exception
- Test: Synthetic guest test
- Action: Remove old link and verify

## Closure checklist
- [ ] Responsibilities explicit.
- [ ] Exceptions linked to inventory.
- [ ] Logging and recovery tested.
- [ ] Drift monitoring has an owner.

## Official sources
- [Microsoft — Protect identities and secrets](https://learn.microsoft.com/en-us/entra/fundamentals/zero-trust-protect-identities)
- [NIST Cybersecurity Framework 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)

https://secnet.work/learn/toolkits/cloud-saas