# Response, impact boundaries and clean recovery

Do not confuse file deletion with containment or service uptime with recovery. Connect identity, persistence, business impact and validation.

Original AI-assisted SecNet educational content. Fictional local examples; not a standards provider publication, endorsement or compliance evidence. Page exercises do not create account progress.

Sources checked: 2026-10-21

## Authorized proportionate containment

Containment needs ownership, scope, service-impact assessment and rollback conditions. When ongoing harm competes with evidence collection, record decision time and rationale. Define emergency authority in advance. Exercise outputs change no real accounts, devices or networks and generate no live response commands. A stopped flag cannot establish that every source is contained.

## Origin and persistent access

Identity or application authority can survive file deletion. Review process, task/service, mailbox-rule and related-account scope. Verify action effects through observed outcomes, such as denied old test sessions. Coordinate collection and authority changes with clear owners. Record rationale and side effects in the incident timeline rather than filling the report with assumed successes afterward.

## Functional clean recovery

HTTP200 or serviceUp is only a technical start. Require a trusted revision, renewed authority, integrity and business-transaction tests. Reverify roles and tenant boundaries. Define monitoring coverage, observation period and who acts if signals recur. Hand over residual risks with owners and deadlines. Notification duties require incident-specific authorized review; the exercise makes no automatic legal breach decision.

## Harbor-17 before closure

Suppose the user deletes the message and report-viewer stops. If session authority, mailbox grants and sensor gaps remain unknown, fileRemoved is not containment. The decision card names missing-evidence owners, controlled constraints and business-validation steps. Observed clean access and legitimate workflows support recovery. This fictional desk performs no isolation or restoration; it teaches which evidence would change a decision.

## Working sequence

1. Record authority/harm/evidence tradeoffs.
2. Constrain origin and persistent authority.
3. Observe side effects and old-access outcomes.
4. Validate business flows on a trusted revision.
5. Complete monitoring and residual-risk handover.

## 1. File removed

File removal does not close identity, persistence or related scope. Deletion evidence alone cannot establish completed containment.

This code is a local policy model; it does not replace target/cluster testing.

### Weak implementation
```js
s=>s.fileRemoved
```

### Corrected implementation
```js
s=>s.fileRemoved&&s.identityContained&&s.persistenceReviewed&&s.relatedScopeReviewed
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "supported-case",
      "input": {
        "fileRemoved": true,
        "identityContained": true,
        "persistenceReviewed": true,
        "relatedScopeReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "delete-only",
      "input": {
        "fileRemoved": true,
        "identityContained": false,
        "persistenceReviewed": false,
        "relatedScopeReviewed": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "identity-still-active",
      "input": {
        "fileRemoved": true,
        "identityContained": false,
        "persistenceReviewed": true,
        "relatedScopeReviewed": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "supported-case",
      "input": {
        "fileRemoved": true,
        "identityContained": true,
        "persistenceReviewed": true,
        "relatedScopeReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "delete-only",
      "input": {
        "fileRemoved": true,
        "identityContained": false,
        "persistenceReviewed": false,
        "relatedScopeReviewed": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "identity-still-active",
      "input": {
        "fileRemoved": true,
        "identityContained": false,
        "persistenceReviewed": true,
        "relatedScopeReviewed": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 2. Isolate immediately

An isolation request is not authority or impact planning. Require authorized scope, evidence plan and rollback; this model isolates no real device.

This code is a local policy model; it does not replace target/cluster testing.

### Weak implementation
```js
s=>s.isolationRequested
```

### Corrected implementation
```js
s=>s.isolationRequested&&s.authorized&&s.impactReviewed&&s.evidencePlan&&s.rollbackDefined
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "supported-case",
      "input": {
        "isolationRequested": true,
        "authorized": true,
        "impactReviewed": true,
        "evidencePlan": true,
        "rollbackDefined": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "unapproved-disruption",
      "input": {
        "isolationRequested": true,
        "authorized": false,
        "impactReviewed": false,
        "evidencePlan": true,
        "rollbackDefined": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "no-evidence-plan",
      "input": {
        "isolationRequested": true,
        "authorized": true,
        "impactReviewed": true,
        "evidencePlan": false,
        "rollbackDefined": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "supported-case",
      "input": {
        "isolationRequested": true,
        "authorized": true,
        "impactReviewed": true,
        "evidencePlan": true,
        "rollbackDefined": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "unapproved-disruption",
      "input": {
        "isolationRequested": true,
        "authorized": false,
        "impactReviewed": false,
        "evidencePlan": true,
        "rollbackDefined": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "no-evidence-plan",
      "input": {
        "isolationRequested": true,
        "authorized": true,
        "impactReviewed": true,
        "evidencePlan": false,
        "rollbackDefined": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 3. Service is up again

Uptime does not establish clean authority or business validation. Integrity, business tests and ready monitoring are needed before completion claims.

This code is a local policy model; it does not replace target/cluster testing.

### Weak implementation
```js
s=>s.serviceUp
```

### Corrected implementation
```js
s=>s.serviceUp&&s.identityReset&&s.integrityVerified&&s.businessTestPassed&&s.monitoringReady
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "supported-case",
      "input": {
        "serviceUp": true,
        "identityReset": true,
        "integrityVerified": true,
        "businessTestPassed": true,
        "monitoringReady": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "up-only",
      "input": {
        "serviceUp": true,
        "identityReset": false,
        "integrityVerified": false,
        "businessTestPassed": false,
        "monitoringReady": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "no-business-test",
      "input": {
        "serviceUp": true,
        "identityReset": true,
        "integrityVerified": true,
        "businessTestPassed": false,
        "monitoringReady": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "supported-case",
      "input": {
        "serviceUp": true,
        "identityReset": true,
        "integrityVerified": true,
        "businessTestPassed": true,
        "monitoringReady": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "up-only",
      "input": {
        "serviceUp": true,
        "identityReset": false,
        "integrityVerified": false,
        "businessTestPassed": false,
        "monitoringReady": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "no-business-test",
      "input": {
        "serviceUp": true,
        "identityReset": true,
        "integrityVerified": true,
        "businessTestPassed": false,
        "monitoringReady": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## Exit evidence

- Authority/scope/impact/rollback decision card
- Old-access denial and clean-business-flow evidence

## References

- [NIST SP 800-61 Rev.3 · Final April 2025](https://csrc.nist.gov/pubs/sp/800/61/r3/final)
- [Microsoft Entra · Revoke user access](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access)