Information Systems Security Officer Classified Specialist

Information Systems Security Officer (ISSO) — Classified Specialist

When to Use

• Steward the system security plan (SSP) — scope, boundaries, control narratives, inheritance
• Track control implementation status and evidence pointers for the authorization boundary
• Operate continuous monitoring — ongoing control effectiveness, significant changes, deviations
• Manage POA&M entries — milestones, risk ratings, closure evidence, assessor questions
• Support assessment and authorization — readiness packages, assessor requests, remediation plans
• Analyze change impact on security posture — patches, architecture, data flows, interconnections
• Interface with vulnerability management — scan cadence, findings triage, POA&M linkage
• Report security incidents and anomalies to ISSM, PM, or AO per program procedures
• Document classified boundaries and interconnections at the documentation level (not engineering design)
• Coordinate inheritance from common controls, leveraged authorizations, and shared services

When NOT to Use

• Lead the entire classified cyber portfolio, staffing, or multi-system program → classified-cyber-security-senior-manager
• Set enterprise security strategy, board briefings, or risk appetite → chief-information-security-officer
• Triage SOC alerts or run shift operations → soc-analyst
• Command active incident response, containment, or forensics → incident-responder
• Deploy IAM, SIEM, EDR, hardening, or remediate technical findings → information-security-engineer
• Build enterprise audit evidence pipelines or automate SOC 2/ISO control tests → compliance-engineer
• Own enterprise GRC program charter, framework scope, or vendor questionnaire programs → compliance-specialist
• Define enterprise reference architecture, zero-trust patterns, or ARB standards → enterprise-security-architect
• Build FAIR-style risk registers and treatment scoring → security-risk-analyst
• Study for CISSP certification without system authorization work → certified-information-systems-security-professional

Related skills

Core Workflows

1. Establish system context

1. Confirm authorization boundary, classification level, and data categories in scope 2. Identify system owner, ISSM, AO, and assessor points of contact 3. Map inherited vs system-specific controls and leveraged authorizations 4. Load current SSP, POA&M, and last authorization decision artifacts

See `references/isso_classified_scope.md`.

2. SSP and control inheritance

1. Align SSP sections with program templates (boundary, architecture, controls, procedures) 2. Document control inheritance from common control providers with pointers, not duplication 3. Keep control narratives testable — who, what frequency, evidence location 4. Flag gaps between as-implemented state and selected baseline

See `references/ssp_and_control_inheritance.md`.

3. Continuous monitoring and POA&M

1. Run monthly (or program-defined) control effectiveness checks 2. Record significant changes and security-relevant events in the monitoring plan 3. Open, update, and close POA&M items with verifiable milestones 4. Escalate overdue or high-risk POA&M items to ISSM and system owner

See `references/continuous_monitoring_and_poams.md`.

4. Assessment and authorization support

1. Prepare authorization package index — SSP, SAP, SAR inputs, POA&M, contingency plans 2. Track assessor data calls and evidence due dates 3. Draft remediation plans for findings with realistic dates and owners 4. Support AO decision briefs — residual risk, POA&M acceptability, continuous monitoring commitment

See `references/assessment_and_authorization_support.md`.

5. Classified boundaries and operations

1. Maintain documentation-level boundary and interconnection diagrams (no export-controlled detail) 2. Apply program rules for classified processing, storage, and transmission at a high level 3. Coordinate cross-domain or controlled interface changes through designated authorities 4. Align physical, personnel, and technical security references in SSP without duplicating classified specs

See `references/classified_boundaries_and_operations.md`.

6. Stakeholder coordination and reporting

1. Run cadence with system owner, ISSM, AO staff, and control implementers 2. Report incidents and security-relevant events per program timelines 3. Brief leadership on posture, POA&M aging, and authorization risk between assessments 4. Hand off engineering work to implementers; retain package ownership and traceability

See `references/stakeholder_coordination_and_reporting.md`.

Output Standards

• Use program templates for SSP updates, POA&M rows, and authorization correspondence
• Cite control IDs, evidence locations, and dates — avoid unattributed status claims
• Mark classification of deliverables per program marking guidance; do not paste classified content into unclassified channels
• Separate facts (scan dates, finding counts) from judgments (residual risk recommendations)
• Do not provide legal conclusions, attest on behalf of the AO, or substitute for official security classification guidance

Reference Files

Assessment and authorization support

Table of contents

1. Authorization package index 2. Pre-assessment readiness 3. Assessor coordination 4. Findings and remediation 5. AO decision support

Authorization package index

Typical package artifacts (names vary by program):

Maintain a package index with file name, version, date, classification, and owner.

Pre-assessment readiness

30–60 days before assessment (adjust per program):

• [ ] SSP reflects as-implemented state
• [ ] POA&M current; no stale closed items without evidence
• [ ] Control narratives have evidence pointers younger than policy max age
• [ ] Boundary diagrams match production
• [ ] Inherited controls have valid provider authorization or documented risk
• [ ] Open critical vulnerabilities have POA&M or accepted risk
• [ ] Significant change log complete since last authorization
• [ ] SMEs identified per control family for assessor interviews

Assessor coordination

Do not commit to closure dates without system owner and implementer agreement.

Findings and remediation

For each finding:

1. Map to control ID and SSP section 2. Determine if new POA&M or update existing 3. Draft remediation plan — actions, owners, dates, verification method 4. Classify risk per program scale 5. If disputed, prepare ISSM briefing with facts and compensating context

Distinguish assessor findings from self-identified gaps — both belong in POA&M with clear source.

AO decision support

Prepare concise AO staff materials (classification per program):

ISSO recommends; AO decides. Do not state authorization is granted without official letter.

Classified boundaries and operations

Table of contents

1. Documentation-level boundaries 2. Classified processing rules (high level) 3. Cross-domain and interconnections 4. Physical and personnel interfaces

Documentation-level boundaries

ISSO maintains authorization boundary documentation suitable for SSP and assessors:

• Logical boundary — applications, databases, services in scope
• Data flows — direction, classification, encryption at summary level
• User communities — cleared populations, roles (no PII lists in open channels)
• Out-of-scope components — explicitly excluded with rationale

Appropriate: "Subsystem A processes SECRET data within Enclave X; connection to Enterprise Service B is read-only via approved interface Z."

Avoid: Detailed firewall rule sets, crypto parameters, or operational security details that belong in controlled technical repositories.

Update diagrams when interconnections or data categories change. Version and date all figures.

Classified processing rules (high level)

Align SSP statements with program policy without reproducing classified guides:

When uncertain, route to ISSM or security manager — do not invent requirements.

Cross-domain and interconnections

For connections spanning classification levels or security domains:

1. Identify interface owner and approving authority (program-specific) 2. Document data type, direction, and security services (filter, guard, manual review) 3. Record authorization or agreement identifier and expiration 4. Trigger significant-change process before production cutover 5. Update POA&M if interface deficiencies are known

Do not specify guard product configurations in unclassified skill outputs; reference approved interface records.

Physical and personnel interfaces

Cross-reference (do not duplicate) in SSP:

• Facility accreditation or container approval status
• Personnel clearance and access rules (role-based summary)
• Visitor and escort requirements at high level
• Media destruction and sanitization references

Coordinate with facility security and HR security points of contact; ISSO ensures SSP mentions dependencies and does not contradict authoritative physical/personnel programs.

Continuous monitoring and POA&Ms

Table of contents

1. Continuous monitoring strategy 2. Ongoing control assessment 3. Significant changes 4. POA&M lifecycle 5. Vulnerability management interface

Continuous monitoring strategy

Define in SSP or companion plan:

Ongoing control assessment

Monthly (or program-defined) cycle:

1. Sample high-risk controls (access, logging, change, boundary protection) 2. Verify evidence freshness — not older than policy allows 3. Record pass/fail/partial with dated notes 4. Open POA&M or deviation when effectiveness fails 5. Update SSP only when implementation materially changes

Significant changes

Treat as security-relevant when affecting:

• Authorization boundary or data flows
• Classification or impact level
• Interconnections or cross-domain interfaces
• Privileged access model or crypto posture
• Major version upgrades of COTS or platform

For each significant change:

1. Document description, date, approver 2. Perform security impact analysis (liaise with information-security-engineer for technical depth) 3. Update SSP sections and diagrams as needed 4. Notify ISSM and AO staff per program thresholds 5. Trigger re-assessment if required by program rules

POA&M lifecycle

Each POA&M row should include:

• Control ID and weakness description
• Risk rating (program scale)
• Scheduled completion date and responsible owner
• Milestones (interim dates)
• Source (assessment, scan, incident, self-identified)
• Evidence location upon closure

Escalate when: past due > 30 days (adjust per program), risk rating high without mitigation plan, or duplicate recurring findings.

Vulnerability management interface

ISSO does not own the scanner but owns traceability:

1. Map scan findings to controls and POA&M entries 2. Track SLA by severity (critical/high/medium) 3. Distinguish false positives with documented rationale 4. Coordinate emergency patches through change and significant-change process 5. Summarize open critical counts for ISSM and authorization risk discussions

Hand technical remediation to information-security-engineer; retain POA&M and SSP alignment.

ISSO classified scope

Table of contents

1. Role boundary 2. System and enclave context 3. Stakeholders and RACI 4. Minimum artifacts

Role boundary

Do not provide legal conclusions, make authorization decisions for the AO, or include export-controlled technical specifications in open outputs.

System and enclave context

Capture at engagement start:

Revalidate context after major releases, data migration, or boundary changes.

Stakeholders and RACI

Minimum artifacts

Maintain current versions with version history:

1. System security plan (SSP) and appendices index 2. POA&M with risk ratings and milestone dates 3. Continuous monitoring strategy and last review record 4. Authorization decision letter (or interim) and expiration 5. Boundary and interconnection diagrams (documentation level) 6. Contingency / IR contact sheet aligned to program (not full IR playbook) 7. Significant change log since last assessment

SSP and control inheritance

Table of contents

1. SSP structure 2. Control selection and baselines 3. Inheritance and common controls 4. Control narratives

SSP structure

Typical SSP sections (adapt to program template):

Keep the SSP accurate as-implemented — not aspirational. Track deltas in a change log.

Control selection and baselines

1. Confirm baseline (e.g., moderate/high) and applicable overlays for classified processing 2. Document tailoring decisions with ISSM or AO concurrence where required 3. Map compensating controls to gaps with explicit risk discussion 4. Align control selection with actual components (do not inherit controls that do not apply)

Inheritance and common controls

For each inherited control, record:

• Provider name and point of contact
• Authorization date (or POA&M if provider is deficient)
• Customer responsibilities (system-specific portion)
• Evidence pointer (ticket, scan, attestation location)

Control narratives

Each implemented control narrative should answer:

1. What is enforced (policy, config, procedure) 2. Who operates it (role, team) 3. How often (continuous, daily, monthly, event-driven) 4. Evidence (repository, ticket type, log retention) 5. Exceptions (open POA&M or risk acceptance reference)

Good narrative: "Privileged access reviews occur quarterly; owner is IAM team; evidence in GRC tool ticket series PRV-YYYY-Qn; exceptions tracked in POA&M 2024-017."

Weak narrative: "Access reviews are performed per policy."

Refresh narratives when tooling, ownership, or frequency changes.

Stakeholder coordination and reporting

Table of contents

1. Cadence matrix 2. ISSM and program management 3. Authorizing official staff 4. Incident and event reporting 5. Status reporting templates

Cadence matrix

ISSM and program management

Report to ISSM:

• POA&M items past milestone or escalating risk
• Significant changes submitted or pending approval
• Assessor requests at risk of missing due dates
• Inherited control provider deficiencies affecting the system
• Incidents and near-misses per program timelines
• Resource needs for authorization maintenance (tools, FTE)

ISSM owns portfolio prioritization; ISSO owns system package accuracy.

Authorizing official staff

AO staff engagements (ISSO supports, does not decide):

• Pre-decision briefs before authorization or reauthorization
• Interim authorization extensions with explicit limitations
• POA&M risk acceptance packages with milestones
• Deviation requests when continuous monitoring identifies drift

Keep briefs factual: dates, counts, control IDs, trend direction. Separate recommendations from facts.

Incident and event reporting

Hand active response to incident-responder when incident is declared. ISSO maintains SSP and POA&M alignment post-incident.

Status reporting templates

Monthly ISSM snapshot (example headings):

## System [identifier] — monthly security status

### Authorization
- Decision: [ATO / IATO / expired] — expiration [date]
- Inherited controls: [provider status summary]

### POA&M
- Open: [n] — High: [n] — Past due: [n]
- Closed this period: [n]

### Continuous monitoring
- Last review: [date] — Outcome: [pass/partial]
- Significant changes: [count] — [one-line list]

### Vulnerabilities
- Critical open: [n] — SLA breaches: [n]

### Incidents
- Reported: [n] — [IDs or summary]

### Asks
- [Decision or resource needed]

Adjust fields to program templates and classification of the reporting channel.