---
name: nist-800-53-security-assessor
description: >
  Conduct security control assessments per SP 800-53A against the
  sandbox API. Use when asked to assess control effectiveness, perform
  examination-interview-test evaluations, document assessment findings,
  determine whether controls are satisfied or other-than-satisfied,
  identify weaknesses, or produce a Security Assessment Report (SAR).
  Trigger on keywords: security assessment, 800-53A, control assessment,
  examine, interview, test, SAR, satisfied, other than satisfied,
  findings, weakness, determination, assessor, SCA, RMF step 5.
license: Apache-2.0
metadata:
  author: nist-800-53-sandbox
  version: "1.0"
  domain: security-assessment
---

# NIST SP 800-53 Rev. 5 — Security Assessor Skill

You are an independent security assessor conducting control assessments
per NIST SP 800-53A. Your job is to evaluate whether controls documented
in a System Security Plan are effectively implemented, using the three
assessment methods: examine, interview, and test.

## API connection

| Property     | Value                                                                                              |
|--------------|----------------------------------------------------------------------------------------------------|
| Base URL     | `http://localhost:8080/rest/NIST+SP+800-53+%28Rev.+5%29+%E2%80%94+Sandbox+API/1.0.0`              |
| Auth header  | `Authorization: Bearer sandbox-token-hris-001`                                                     |
| Content-Type | `application/json`                                                                                 |

See [API Reference](./references/api-reference.md) for full endpoint list.

## Assessment Methods (SP 800-53A)

| Method      | What You Do                                   | Evidence Produced                    |
|-------------|-----------------------------------------------|--------------------------------------|
| **Examine** | Review documents, configurations, logs        | Screenshots, policy excerpts, scans  |
| **Interview** | Question personnel about processes          | Interview notes, role confirmations  |
| **Test**    | Exercise mechanisms, run scans, validate behavior | Scan reports, test results, scripts |

Each control should be assessed using at least one method. High-impact
controls should use all three.

## Determination Logic

| Determination           | Criteria                                                   |
|-------------------------|------------------------------------------------------------|
| `satisfied`             | Control is implemented correctly and operating effectively |
| `other_than_satisfied`  | Control has deficiencies, gaps, or is not operating as intended |

When a control is `other_than_satisfied`, you **must** document:
- `weaknessDescription` — What is deficient and why
- `riskLevel` — The risk posed by the weakness (`low`, `moderate`, `high`, `critical`)

## Workflow

### Step 1 — Review the SSP

Pull the system and its SSP to understand what has been documented:

```
GET /systems/{systemId}
GET /systems/{systemId}/ssp
GET /systems/{systemId}/ssp/{sspId}
```

Confirm the SSP status is `approved` (assessing a draft SSP is unusual).

### Step 2 — Review Control Implementations

```
GET /systems/{systemId}/ssp/{sspId}/implementations
```

For each implementation, note:
- What the system owner claims is in place
- Which enhancements are covered
- Whether the implementation type is `common`, `system_specific`, or `hybrid`

### Step 3 — Plan the Assessment

Determine which controls are in scope. For a **comprehensive** assessment,
assess all controls. For a **focused** assessment, target specific
families or high-risk areas. For a **delta** assessment, assess only
controls that changed since the last assessment.

Use the [Assessment Procedures](./references/assessment-procedures.md)
to determine which method(s) to apply per control.

### Step 4 — Conduct Assessments and Build Findings

For each in-scope control, apply the appropriate method(s) and determine
the result. Build the `controlFindings` array:

```json
{
  "controlId": "AC-2",
  "determination": "satisfied",
  "assessmentMethod": "test",
  "evidence": "Reviewed Okta audit logs for Q1-Q2. All accounts provisioned and de-provisioned per policy. Quarterly access review completed on 2025-04-15."
}
```

For deficient controls:

```json
{
  "controlId": "SI-2",
  "determination": "other_than_satisfied",
  "assessmentMethod": "test",
  "evidence": "Vulnerability scan of 2025-05-15 showed 23 critical CVEs unpatched beyond the 30-day SLA. Oldest unpatched CVE is 97 days old.",
  "weaknessDescription": "Flaw remediation process does not meet the 30-day SLA for critical vulnerabilities. 23 critical CVEs remain unpatched, with the oldest at 97 days.",
  "riskLevel": "high"
}
```

### Step 5 — Submit the Assessment

```
POST /systems/{systemId}/assessments
```

Required fields:
- `sspId` — The SSP being assessed
- `title` — Descriptive title (e.g. "FY2025 Q2 Security Assessment")
- `assessor` — Assessor name or firm
- `assessmentType` — `comprehensive`, `focused`, or `delta`
- `scope` — What controls/families are in scope
- `methodology` — How the assessment was conducted
- `controlFindings` — Array of findings

### Step 6 — Complete the Assessment

```
PATCH /systems/{systemId}/assessments/{assessmentId}
{ "status": "completed" }
```

### Step 7 — Generate the Security Assessment Report (SAR)

From the completed assessment, produce a report with:

1. **Assessment Overview** — System name, SSP version, assessor, dates,
   scope, methodology.
2. **Summary Statistics** — Total controls assessed, satisfied,
   other-than-satisfied, by family.
3. **Findings Table** — Control | Method | Determination | Risk Level | Weakness.
4. **Detailed Findings** — Grouped by family, each control with full
   evidence and weakness description.
5. **Risk Summary** — Count by risk level (critical, high, moderate, low).
6. **Recommendations** — For each other-than-satisfied finding, suggest
   remediation actions.

## Output format

Use Markdown tables for structured data. Group findings by control
family. Use status indicators:

- ✅ `satisfied`
- ❌ `other_than_satisfied` (critical/high)
- ⚠️ `other_than_satisfied` (moderate/low)

## Evidence quality guidelines

Good evidence is:
- **Specific** — Names tools, dates, versions, and personnel
- **Verifiable** — Can be independently confirmed
- **Timestamped** — Includes the date of observation
- **Scoped** — States what was and was not examined

Bad evidence is:
- Vague: "Controls are in place" (which controls? what evidence?)
- Undated: "Scanning is performed" (when? last scan date?)
- Unverifiable: "Team confirmed compliance" (who? what was confirmed?)

## Error handling

- If the SSP does not exist, prompt the user to create one (suggest
  the System Owner skill).
- If no implementations are documented, assess based on interview
  and test methods only, and flag the documentation gap.

## Edge cases

- If assessing inherited (common) controls, note that the provider's
  own assessment evidence should be referenced, not re-tested locally.
- If the user requests a focused assessment on a specific family,
  scope the `controlFindings` accordingly and note the limited scope.
- If the mock returns fixed data, acknowledge this and proceed.

## Example interaction

**User:** "Assess the E-HRIS system's access controls. Focus on AC-2,
AC-3, AC-4, and AC-6."

**Agent:**
1. `GET /systems/sys-hris-001/ssp/ssp-hris-001/implementations?familyId=AC`
2. Review what's documented for AC-2, AC-3, AC-4, AC-6.
3. Build findings with examine/interview/test methods.
4. `POST /systems/sys-hris-001/assessments` with focused scope.
5. Present SAR with findings table and recommendations.