YPMS/SYSTEM_SECURITY_PLAN.md

System Security Plan (SSP)

Youth Program Management System (YPMS)

Document Version: 0.3 (Draft — in-house build reframe) Date: 2026-09-30 Classification: Controlled Unclassified Information (CUI) — internal DOES use only Status: Pre-Development / Pre-Authorization (drafting alongside team formation and architecture)

Drafting note. YPMS is an in-house build by DOES OIT, matching the DCYWP / OWC / Employer 360 delivery pattern. This SSP derives functional and security requirements from the prior YPMS RFP (Solicitation Docxxxxx, April 2025) — its C.5.7 Security Requirements catalogue (54 requirements), C.5.6 Infrastructure Requirements, C.5.8 Database Requirements, and Attachment E Additional Non-Functional Requirements — as source specifications, not as Contractor obligations. Ownership of controls sits with DOES OIT (implementation), DC OCTO enterprise services (some Hybrid), and Azure Government FedRAMP High (Inherited for physical, environmental, and low-level infrastructure). Items marked [TBD] require completion by DOES leadership before ATO submission. Where a source-RFP requirement is load-bearing for a control statement, its identifier (e.g., C.5.7.9) is cited inline so a reviewer can trace SSP text back to the source spec. Companion documents referenced below live as siblings in ypms/.

---

Table of Contents

1. System Identification
2. System Categorization (FIPS 199)
3. System Owner and Authorizing Official
4. Other Designated Contacts
5. Assignment of Security Responsibility
6. System Operational Status
7. Information System Type
8. General System Description
9. System Environment and Boundary
10. Information Types
11. System Interconnections
12. Related Laws, Regulations, and Policies
13. Privacy Considerations
14. Minimum Security Controls
15. Continuous Monitoring
16. Plan Approval
17. Appendices

---

1. System Identification

Field	Value
System Name	Youth Program Management System
System Acronym	YPMS
System Identifier	[TBD: DOES-issued system ID per DC OCTO inventory]
Operating Organization	District of Columbia, Department of Employment Services (DOES)
Operating Component	Office of Youth Programs (OYP) — business owner / Office of Information Technology — technical owner and implementer
Delivery Model	In-house build by DOES OIT on Azure Government, matching the OWC pattern. Stack: Python 3.12 / FastAPI / SQLAlchemy / Postgres, decision recorded 2026-09-30.
Information System Abstract	Centralized DOES-owned system replacing a fragmented set of legacy tools (Host/Participant Application, Scanning Application, Transfer Application, TMS, MicroStrategy, People First PF3 "backdoor" admin tool, and manual payroll scripts). Automates OYP business processes end-to-end: Online Youth Applications, Eligibility, Certification, Orientation (via LMS integration), Job Matching, Program Enrollments, Host Registration, third-party Payroll distribution, Worksites/Positions Management, Job Postings, Online Time Management, Reports, and Admin Functions. Serves programs MBSYEP, HSIP, MBYLI (SIT/SYP/Global Education), CRESP, and future OYP programs. Target Go-Live: beginning of FY2027 per source RFP C.5.2.11; effective slip acknowledged pending team formation, stack decision, and iterative build.

---

2. System Categorization (FIPS 199)

Determined per FIPS 199 Standards for Security Categorization of Federal Information and Information Systems and FIPS 200 Minimum Security Requirements for Federal Information and Information Systems. YPMS processes information subject to categorization guidance in NIST SP 800-60 Vol. II for youth workforce, benefits, and PII information types.

2.1 Security Objectives

Security Objective	Categorization	Rationale
Confidentiality	Moderate (with High-sensitivity subsets — see note)	YPMS collects PII on minors (registrants ages 14–24, including under-18 participants), SSN (masked/anonymized per C.5.7.50 but stored for SSA cross-match per C.5.6.4), DOB, residential address, parent/guardian contact, banking information for payroll (C.5.3.8), tax information, school enrollment records ingested from OSSE (subject to FERPA), CFSA records identifying wards of the state and foster youth (C.5.6.3.a.3), and — under contingency scenarios — health records ingested by CSV (C.5.6.3.a.2). Loss of confidentiality would cause significant harm to minors including identity-theft risk, unauthorized disclosure of foster/ward status, and FERPA-covered educational record exposure.
Integrity	Moderate	Eligibility determinations control access to paid summer employment for DC minors; wage payments are computed by YPMS-adjacent payroll integration (C.5.3.8) with tax-form generation. Unauthorized modification of eligibility flags, hours-worked records, employer registrations, or payroll transmissions could enable wage fraud, wrongful denial of eligibility, or IRS reporting errors. Backdated transactions and reprocessing are allowed (C.5.7.17) — heightened integrity controls needed on that path.
Availability	Moderate	Target SLA (adopted from source RFP C.5.6.17) is 99.5% in any rolling 30 days — ≤ 43.2 minutes/month of unplanned downtime. Program impact is seasonally peaked: MBSYEP application windows and payroll cycles are hard deadlines for youth compensation. 24×7 operability required (C.5.6.10).

2.2 Overall System Categorization

Moderate Impact (highest of the three security objective categorizations, per FIPS 199 §3).

Note on High-sensitivity data subsets. Three data classes elevate risk above a typical Moderate profile and require compensating controls even where the aggregate rating remains Moderate:

1. FERPA educational records ingested from OSSE (C.5.6.3.a.1) — treated per FERPA and the DOES–OSSE data-sharing agreement.
2. CFSA foster-care / ward-of-state records (C.5.6.3.a.3) — DC Code Title 4 confidentiality applies; access strictly limited on need-to-know.
3. Contingent health records (COVID-era CSV pathway per C.5.6.3.a.2) — HIPAA-adjacent; DOES is not a covered entity for these, but reasonable safeguards apply and the ingest path is dormant except during declared emergencies.

The initial FIPS 199 categorization memo (ypms/FIPS_199_MEMO.md — to be authored) records the AO's disposition on whether any of these subsets warrant a High-water-mark categorization for the whole system.

2.3 Applicable Control Baseline

NIST SP 800-53 Rev. 5 Moderate baseline, tailored as documented in §14. Explicitly cited by the RFP:

• NIST SP 800-53 (C.5.7.51, RFP §C.2 Item 10).
• NIST SP 800-171 Rev. 2 for CUI protection (RFP §C.2 Item 4).
• FIPS 140-2 for cryptographic modules protecting authenticators and data (RFP §C.2 Item 9; C.5.7.9) — implementers should validate to FIPS 140-3 where available (FIPS 140-2 is sunset, though existing validations remain accepted for a defined window).

Overlays under consideration:

• PII overlay (SP 800-53 privacy family — PT/PM).
• FERPA overlay for OSSE-sourced educational records.
• PCI DSS (C.5.6.19) — only if YPMS processes card-present or card-not-present transactions; scope reduction preferred (payroll is ACH via vendor; expected out of scope). See open question §17.E.
• SSA Electronic Information Exchange requirements (C.5.6.4).
• DC OCTO IT Security Policy (C.5.7.53, source RFP §C.2 Item 3).

---

3. System Owner and Authorizing Official

3.1 System Owner

Field	Value
Name	Chris Tonjes
Title	DOES Chief Information Officer
Organization	DC Department of Employment Services
Address	4058 Minnesota Avenue NE, Washington, DC 20019
Phone	(202) 724-7000
Email	ctonjes@gmail.com

3.2 Authorizing Official (AO)

Field	Value
Name	Chris Tonjes
Title	DOES Chief Information Officer, acting as Authorizing Official (see §5 role-concentration note)
Organization	DC Department of Employment Services
Address	4058 Minnesota Avenue NE, Washington, DC 20019
Phone	(202) 724-7000
Email	ctonjes@gmail.com

---

4. Other Designated Contacts

Role	Name	Phone	Email
Information System Security Officer (ISSO)	Chris Tonjes (see §5 role-concentration note)	(202) 724-7000	ctonjes@gmail.com
Privacy Officer	[TBD]	[TBD]	[TBD]
Business Owner — Office of Youth Programs	[TBD]	[TBD]	[TBD]
DOES OIT Delivery Lead	[TBD]	[TBD]	[TBD]
DOES OIT Backend Engineer(s)	[TBD]	[TBD]	[TBD]
DOES OIT Frontend Engineer(s)	[TBD]	[TBD]	[TBD]
DOES OIT Data/Integration Engineer (owns OSSE, CFSA, SSA, DC MAR, payroll integrations)	[TBD]	[TBD]	[TBD]
DOES OIT Test/QA Lead	[TBD]	[TBD]	[TBD]
DOES OIT Database Team Lead	[TBD]	[TBD]	[TBD]
DC OCTO Cloud Coordination POC	[TBD]	[TBD]	[TBD]
DC NOC POC	[TBD]	[TBD]	[TBD]
DC OCTO SOC POC (Sentinel)	[TBD]	[TBD]	[TBD]
Payroll Vendor Security POC	[TBD] — on vendor selection	[TBD]	[TBD]

---

5. Assignment of Security Responsibility

Role-concentration note (accepted risk). Chris Tonjes (DOES CIO) currently holds three roles for YPMS: System Owner, ISSO, and Authorizing Official. FISMA practice usually separates the AO from the system owner and ISSO to preserve independent risk acceptance. DOES is a District agency and the DC CIO / OCTO structure does not require an external AO for agency-scoped systems; the DOES CIO has authority to accept residual risk on behalf of the agency. This concentration is accepted for the initial ATO on the basis that (a) DOES's parent oversight — DC OCTO CISO, USDOL ETA, and OIG when applicable — provides external accountability outside the SSP process, and (b) the initial and annual independent Control Assessments (see §14.4 CA-2) are commissioned from an independent party, giving external technical validation independent of the AO. Future revisions may designate the DOES Director or a peer CIO as AO if a federal partner or OIG review requires strict role separation.

Function	Responsible Party
Overall security responsibility	Chris Tonjes, DOES CIO (System Owner)
Day-to-day security operations	Chris Tonjes, ISSO
Application security	DOES OIT delivery team, under DOES CIO direction
Infrastructure and Azure Government tenant security	DOES OIT, coordinated with DC OCTO per source RFP C.5.6.14
Incident response	DC OCTO CISO Office + DOES OIT (per DC government IRP); breach-notification SLAs derived from source RFP C.5.8.18–C.5.8.20 and adopted as internal DOES policy
SIEM operations	DOES OIT ships logs to DC OCTO Sentinel per YPMS-POAM-043
Personnel security / background checks	DOES HR for DOES staff and any contracted individual developers; DC OCTO clearance requirements apply
Physical / environmental security	Inherited from Azure Government FedRAMP High authorization
Data-access reporting	DOES OIT maintains and reviews a full list of personnel with production data access, updated at least quarterly with additions and deletions tracked
Unauthorized-disclosure notification	DOES OIT to DC OCTO CISO immediately on awareness; full disclosure report within 24 hours; remediation report within 2 business days. Federal-agency notifications on top per Privacy Act and SSA/OSSE/CFSA agreement terms.

---

6. System Operational Status

Pre-Development as of 2026-09-30. No code exists yet. This SSP reflects the target-state YPMS post-build. Interim state during migration:

• Legacy components (Host/Participant Application, Scanning Application, Transfer Application, TMS, MicroStrategy, PF3, Manual Payroll scripts) remain in operation until superseded by phased YPMS releases.
• Delivery is Agile, matching OWC's phased approach (see owc-system/PHASE*_PLAN.md for the reference pattern).
• Go-live milestone per source RFP: major features required for FY 2026 MBSYEP in production by FY 2027 MBYLI school-year registration kick-off; Go-Live at beginning of FY 2027. Effective slip acknowledged pending team formation and architecture kickoff.

Each phase gate triggers an SSP refresh; this document uses semantic versioning (v0.x pre-ATO, v1.0 at initial ATO).

---

7. Information System Type

• Major Application (per NIST SP 800-18 Rev. 1 §2.5). YPMS is a distinct, funded, mission-critical application supporting DOES's statutory obligation to administer District youth employment and workforce-development programs under DC Code Title 32, Chapter 2, Subchapters II and V.
• YPMS is a DOES-built, DOES-operated application on Azure Government. Underlying compute, network, storage, identity, and physical/environmental controls are inherited from Azure Gov's FedRAMP High authorization. Application code is written and maintained by DOES OIT.

---

8. General System Description

8.1 Purpose and Scope

YPMS is the centralized platform for all Office of Youth Programs (OYP) programs, replacing seven legacy tools and a manual payroll process. It supports application intake, eligibility determination, certification events, orientation tracking, job matching and postings, host/employer registration, worksite and position management, online time management, third-party payroll issuance, and reporting.

8.2 Programs Supported

Program	Description
MBSYEP — Marion S. Barry Summer Youth Employment Program	Locally-funded subsidized summer placements for DC youth ages 14–24. Highest peak-load driver.
HSIP — High School Internship Program	School-year academic enrichment, work-readiness, project-based learning for grades 9–12 (ages 14–18).
MBYLI — Marion Barry Youth Leadership Institute	Year-round leadership program including Summer Intensive Training (SIT), School Year Program (SYP), and Global Education Program.
CRESP — Career Ready Early Scholars Program	Middle-school career exploration across 11 tracks (athletics, business, law/global affairs, culinary, agricultural sciences, engineering/design, language arts, STEM, social science/humanities, visual/performance arts, public speaking).
Future OYP programs	System must accept new program definitions from application through completion (C.5.3.1).

Definitional note. The RFP glossary defines "Youth" as "DC resident participants between 99 – 24 years old" (RFP §C.3.1). This is a typographical error; the operative program-eligibility ranges are 14–24 (MBSYEP) and 14–18 (HSIP) with middle-school participants in CRESP. Age band should be corrected in the awarded specification.

8.3 User Populations (per C.5.6.21)

Population	Est. Volume	Access Channel
DOES Users (internal staff and contracted individual developers, plus DOES-approved vendor users)	90	Authenticated internal portal; SSO / DOES global directory (C.5.3.2)
Host Employers (active, inactive, registering)	1,500	Web portal with self-registration
Youth (registering and participating)	27,000	Web portal; social-media login supported (C.5.3.2); minors, some under 18
Parents / Guardians	7,400	Web portal
Other agencies	100	Web portal or interconnection
Total	36,000	—

Scaling target: 50% growth per year (C.5.6.20).

8.4 Functional Capabilities (summary from C.5.3–C.5.6)

• Online youth applications, saved-and-resumed, with demographic, job-preference, education, financial literacy, banking, tax, and supporting documents.
• Auto-eligibility with rules-driven categorical eligibility (C.5.3.3, Appendix D).
• Certification event management with document upload.
• Youth account dashboards, resume builder, job search, program/support-service recommendation.
• LMS integration for orientation tracking (C.5.3.4).
• Host/employer application, worksite management, job posting.
• Online time management with third-party payroll integration (C.5.3.8).
• Tax-form generation (annual) via payroll integration.
• Transportation-voucher tracking.
• Reports and MicroStrategy replacement.
• Admin functions with role-based access.
• 24×7 operability (C.5.6.10).
• <1 second response time (C.5.6.27).
• Modern browser support: latest Chrome, Edge, Safari, Opera (C.5.6.11).
• Multi-environment: minimum two lower + production (C.5.5.1).

---

9. System Environment and Boundary

9.1 Authorization Boundary

The YPMS authorization boundary includes:

1. DOES-authored YPMS application source code and container images (hosted in the DOES git repository under ypms/).
2. Azure Government tenant (compute, network, storage) housing YPMS.
3. Development, test, and production environments (minimum two lower + production per source RFP C.5.5.1); dev and test sanitized of production PII.
4. YPMS application databases (Postgres flexible server on Azure Gov).
5. YPMS-issued APIs and web services (per source RFP C.5.8.15).
6. YPMS-generated audit logs shipped to DC OCTO Sentinel.
7. Encrypted backups (Azure-managed, tested restore).
8. Emerging-technology components (Generative AI / ML / NLP) if enabled, constrained to the DOES domain (source RFP C.5.6.31, C.5.6.32, C.5.7.54) — deferred; tracked as YPMS-POAM-103.

Explicitly out of boundary (but interconnected — see §11):

• Third-party payroll management system.
• DC MAR (address verification).
• SSA Business Services Online (SSN verification, wage data).
• OSSE (school enrollment records).
• CFSA (foster / ward-of-state indicators).
• Third-party orientation LMS.
• Social-media identity providers used for youth login (C.5.3.2).
• DOES global directory / SSO for staff.
• DC OCTO SOC / NOC.
• Emergency health-record CSV source (dormant path per C.5.6.3.a.2).

9.2 Hosting Environment

Azure Government Cloud (aligned with OWC and Employer 360). DOES coordinates cloud infrastructure with DC OCTO per source RFP C.5.6.14. DOES OIT delivers architecture diagrams and technical requirements to OCTO before each significant deployment.

Physical, environmental, media protection, and low-level infrastructure controls are inherited from Microsoft's FedRAMP High authorization for Azure Government. DOES OIT hardens tenant-level configuration to at least the CIS Microsoft Azure Foundations Benchmark plus DOES-specific overlays.

9.3 Network Architecture (target)

[TBD: DOES OIT to deliver as part of the architecture document — tracked as YPMS-POAM-040.] Source RFP mandates that carry over:

• Trusted-zone / transition-zone / untrusted-zone segmentation (C.5.7.23).
• Redundant systems at each tier to eliminate single points of failure (C.5.6.18).
• Load distribution across multiple hosting platforms for failover (C.5.6.29).
• Failover to a remote site for patching without service interruption (C.5.6.13).
• 99.5% availability SLA (C.5.6.17).
• IDS/IPS with alerting (C.5.7.26).
• SIEM with configurable aggregation and alerting (C.5.6.9 #19–23).

9.4 Software Baseline (target)

Layer	Component	Notes
Application platform	Python 3.12 / FastAPI (matching OWC).	Confirmed 2026-09-30.
ORM / DB access	SQLAlchemy 2.x with Alembic migrations.	Matches OWC.
Frontend	Server-rendered Jinja2 templates plus HTMX (matching OWC), with progressive-enhancement JS where needed.	Public youth/host portal may require richer client — decision at architecture phase.
Database	PostgreSQL flexible server on Azure Gov (private endpoint).	Data dictionary and physical model per source RFP C.5.8.4, C.5.8.5, C.5.8.7.
Cryptographic module	FIPS 140-3 validated (140-2 acceptable during deprecation window).	Managed via Azure Key Vault (Gov / HSM).
Directory / identity — internal (staff)	Entra ID (DOES tenant); conditional access with MFA.	LDAP-compliant per source RFP C.5.7.30.
Identity — external (host / youth)	Entra External ID or equivalent; social-media login optional for browsing.	See open question §17.D.
Payroll integration	Third-party payroll vendor.	Vendor selection tracked as YPMS-POAM-023.
LMS integration	Third-party orientation LMS.	Vendor [TBD].
Endpoint (internal user)	DOES-issued device with DC OCTO baseline.	Compliant with DC OCTO IT policy (source RFP C.5.6.30, C.5.7.53).
Emerging-tech (optional)	GenAI/ML/NLP components, constrained to DOES domain.	Deferred; tracked as YPMS-POAM-103.

---

10. Information Types

Per NIST SP 800-60 Vol. II mission-based information type mapping, tailored for YPMS:

Information Type	800-60 Ref	C	I	A	Notes
Personal Identity and Authentication	C.2.8.1	M	M	L	Youth PII: name, SSN, DOB, address, parent/guardian contact.
Youth Development / Workforce Investment	C.3.4.5	M	M	M	Program participation, eligibility, hours worked.
Benefits Administration	C.3.4.2	M	M	M	Wage subsidy issuance via payroll integration.
Revenue Collection (tax reporting)	C.3.4.3	M	M	L	Annual W-2 / tax forms generated.
Educational Records (FERPA)	C.3.1.2	M–H	M	L	OSSE school enrollment; access strictly limited.
Social Services (foster / ward status)	C.3.4.7	H	M	L	CFSA data — DC Code Title 4 confidentiality.
Health Information (contingent)	C.3.3.2	H	M	L	Dormant unless emergency-declared per C.5.6.3.a.2.
Information Management	C.3.1.3	M	M	M	Case, workflow, notification, audit logs.

Provisional aggregate categorization: Moderate, with High-sensitivity data class handling documented in §13 and enforced by role-based least-privilege access under §14.1.

---

11. System Interconnections

Interconnection Security Agreements (ISAs) or equivalent MOUs to be drafted per NIST SP 800-47 Rev. 1 for each of the following.

Interconnected System	Direction	Data	Boundary Protection	Authority
Third-party Payroll Management System	Bidirectional	Hours worked, banking, tax IDs, payroll runs, tax forms	HTTPS + certificate-pinning per source RFP C.5.6.5; FIPS-approved crypto	Vendor agreement + ISA YPMS-POAM-023
SSA (Business Services Online)	Outbound	SSN and identity elements for verification	Per SSA Electronic Information Exchange Security Requirements (C.5.6.4)	SSA data-exchange agreement
OSSE — School Enrollment	Inbound CSV (C.5.6.3.a.1)	Student unique identifiers, enrollment status	Secure file transfer [TBD]	DOES-OSSE data-sharing agreement — must reference FERPA
CFSA — Foster / Ward Indicators	Inbound CSV (C.5.6.3.a.3)	Ward-of-state, foster status	Secure file transfer [TBD]	DOES-CFSA MOU — DC Code Title 4
Third-party Orientation LMS	Bidirectional	Youth orientation completion status	HTTPS API	Vendor agreement [TBD]
DC MAR (Address Verification)	Outbound query	Address strings for validation	HTTPS	DC OCTO service agreement
DOES SSO / Global Directory	Outbound authn	Staff identity assertions	LDAP over TLS (C.5.7.30)	Internal DOES/OCTO
Social-media Identity Providers (youth login)	Inbound authn	OAuth-style identity assertions	HTTPS, provider-hosted	See §17.D open question — risk documented
Emergency Health-Record CSV Source (dormant)	Inbound CSV (C.5.6.3.a.2)	Health records under emergency declaration only	Secure file transfer [TBD] — activated only under declared emergency	Emergency-specific MOU [TBD]
DC OCTO SIEM / SOC	Outbound telemetry	Security event log stream (C.5.6.9 #19–20)	Encrypted syslog / API	DC OCTO CISO agreement
DC NOC	Bidirectional operational	Availability and change coordination (C.5.6.17)	Ticketing/paging	Internal DC OCTO
IRS (indirect, via payroll vendor)	Outbound	W-2 / 1099 issuance	Payroll vendor handles per IRS specs	Vendor-mediated
DOES-authored ypms/ doc set	Internal	Requirements, SSP, control mapping, POA&M, PIA, IRP, CP, RoB	DOES-managed git repo	Internal

---

12. Related Laws, Regulations, and Policies

12.1 Federal

• Federal Information Security Modernization Act (FISMA), 44 USC §3551 et seq.
• NIST SP 800-53 Rev. 5 — cited by C.5.7.51 and RFP §C.2 Item 10.
• NIST SP 800-171 Rev. 2 — RFP §C.2 Item 4.
• NIST SP 800-37 Rev. 2 (RMF).
• FIPS 199 / FIPS 200 categorization.
• FIPS 140-2 (with FIPS 140-3 forward alignment) — RFP §C.2 Item 9 and C.5.7.9.
• Family Educational Rights and Privacy Act (FERPA), 20 USC §1232g — for OSSE-sourced records.
• Privacy Act, 5 USC §552a — RFP §C.2 Item 7.
• Section 1106 of the Social Security Act — RFP §C.2 Item 7.
• Health Insurance Portability and Accountability Act (HIPAA) — reasonable-safeguards alignment for the dormant health-record path (DOES not a covered entity for these records).
• Fair Labor Standards Act (FLSA) — youth employment provisions inform hours/eligibility rules.
• Section 508 of the Rehabilitation Act (§C.2 Item 6) and WCAG 2.1 AA.
• IEEE Standard 828-2012 — Configuration Management (RFP §C.2 Item 8).
• PCI DSS (C.5.6.19) — if card payments are in scope.

12.2 District

• DC Code Title 32, Chapter 2, Subchapters II and V (Mayor's Youth Leadership Institute) — RFP §C.2 Items 1–2.
• DC Code Title 4 — CFSA confidentiality.
• DC OCTO Technical Policy, Requirements, and Standards — RFP §C.2 Item 3, C.5.7.53, C.5.6.8.
• DC Language Access Act of 2004 — RFP §C.2 Item 5.
• DC OCTO IT Security Policy (current version).
• DC Public Records / FOIA (DC Code §2-531 et seq.).

12.3 Standards and Guidance

• OWASP ASVS Level 2 (target for DOES OIT delivery).
• OWASP API Security Top 10 — C.5.8.15 APIs.
• SANS Information Logging Standard — C.5.6.9 #18.
• SSA Electronic Information Exchange Security Requirements — C.5.6.4.

---

13. Privacy Considerations

A Privacy Impact Assessment (PIA) will be authored in parallel to this SSP as ypms/PRIVACY_IMPACT_ASSESSMENT.md; findings that alter the boundary or control set are reflected here at each revision.

• PII collected: name, SSN, DOB, address(es), phone(s), email, parent/guardian contact, employment history, banking (for payroll direct deposit), tax information, education records (from OSSE), foster/ward status (from CFSA), resume content, application answers, hours worked, orientation completion.
• Sensitive PII: SSN, banking, foster/ward status, contingent health records.
• Minors: A majority of registrants are minors. All PII-handling defaults must reflect this (data minimization, parental consent workflows where required, no dark-pattern retention).
• Legal basis: DC Code Title 32; DOES statutory responsibility for youth workforce programs.
• Minimization: Category-eligible determinations should reuse data across programs (C.5.3.3) rather than re-collecting; the RFP anticipates this.
• SSN handling: SSN must be masked/anonymized in display contexts (C.5.7.50) and encrypted at rest and in transit (C.5.7.25).
• Retention: [TBD] — align with DOES records schedule and OYP program-specific retention. Backups delivered to DOES daily per C.5.8.21 — retention of those backups is DOES's responsibility once received.
• Notice: Privacy notice presented at first youth/host contact; parental notice where the registrant is a minor.
• Individual participation: Users can view and update profile records (C.5.7.19, C.5.7.21, C.5.7.22).
• Language access: DC Language Access Act obligations (§12.2) — notices and portal content in required languages.
• Emergency health-record path: dormant by default. Activation requires a separate emergency-scoped PIA addendum, retention schedule, and destruction plan.

---

14. Minimum Security Controls

This section documents the NIST SP 800-53 Rev. 5 Moderate baseline as tailored for YPMS. Full control statements are maintained in ypms/NIST_800_53_CONTROL_MAPPING.md, analogous to the DCYWP NIST_800_53_CONTROL_MAPPING.md. The summary below records the tailoring rationale for each family and identifies which side of the line (DOES OIT / Hybrid / Inherited from Azure Gov or DC OCTO / Organizational) each control lives on. Cross-references to specific source-RFP requirements (C.5.x.y) are load-bearing: every control listed here has at least one source-RFP requirement it responds to; the full inverse index is in Appendix C.

Legend: DOES OIT (DOES OIT implements and operates in the YPMS codebase and Azure tenant), Hybrid (DOES OIT + DC OCTO enterprise services), Inherited (from Azure Government FedRAMP High or DC OCTO enterprise), Organizational (DOES policy/process/training).

14.1 Access Control (AC)

• AC-2 Account Management — DOES OIT. Admin capability to enable/disable users (C.5.7.5), auto-disable after inactivity (C.5.7.4), unique user IDs no shorter than 12 alphanumeric characters (C.5.7.7), no re-issue of deleted or previously-assigned user IDs (C.5.7.47).
• AC-3 Access Enforcement — DOES OIT. Server-side authorization on every action (C.5.7.27); admin-only view/change of access rights (C.5.7.28); group- and user-level assignment (C.5.7.29); real-time and scheduled access-change effectivity (C.5.7.31).
• AC-4 Information Flow Enforcement — DOES OIT. Trusted/transition/untrusted zone segmentation (C.5.7.23); untrusted systems cannot reach trusted-zone systems directly.
• AC-6 Least Privilege — DOES OIT. Role-based access control (C.5.7.32, C.5.7.34); one login per staff user with role-mediated function access (C.5.7.33). Separation of duties: youth-facing self-service (C.5.7.20) separated from admin bulk-update paths; CFSA/OSSE data reachable only by role-flagged users.
• AC-7 Unsuccessful Logon Attempts — DOES OIT. Lockout after 5 attempts (C.5.7.10); revoked-access notification (C.5.7.11).
• AC-8 System Use Notification — DOES OIT. Notification before granting access (C.5.7.37).
• AC-11 Session Lock / AC-12 Session Termination — DOES OIT. Idle-timeout session expiry with re-authentication (C.5.7.3).
• AC-17 Remote Access — DOES OIT. All access is remote by architecture; MFA required for staff and admin (see IA-2).
• AC-19 Access Control for Mobile Devices — DOES OIT. Mobile-platform design conforms to encryption, access control, and application security principles (C.5.7.35); endpoints comply with DC OCTO policy (C.5.6.30).
• AC-20 Use of External Systems — Hybrid. Governs employer/host access and third-party integrations (payroll, LMS, social-media login).
• AC-22 Publicly Accessible Content — DOES OIT. Public content reviewed before publication.

14.2 Awareness and Training (AT)

• AT-2 / AT-3 / AT-4 — Hybrid. DOES annual security awareness; role-based training for OYP staff (adjudication, eligibility, payroll admin) and any contracted individual developers. Training program derived from source RFP C.5.9.

14.3 Audit and Accountability (AU)

• AU-2 Event Logging — DOES OIT. Comprehensive event list from C.5.7.39: all root/admin actions, audit-log access/modification, successful and unsuccessful logon attempts, password changes, system-level object create/delete, all interactions with PII or other sensitive data, plus organization-defined additional events. Role changes, system shutdown/restart, file access authorized and unauthorized, and user logon events per C.5.6.9 #4.
• AU-3 Content of Audit Records — DOES OIT. What/when/where/source/outcome/identity per C.5.7.48; sufficient detail to reconstruct events (C.5.7.49); user identification and timestamp captured on any create/modify/delete (C.5.7.15); unique transaction number per transaction (C.5.6.9 #11); before-and-after transaction history (C.5.6.9 #8); communication send/access logging (C.5.6.9 #12, #13).
• AU-4 Storage Capacity / AU-5 Response to Audit Logging Process Failures — DOES OIT. Alerts to admins and additional roles on security compromise (C.5.7.26); user-account lockout alerts (C.5.6.9 #23).
• AU-6 Audit Review, Analysis, and Reporting — Hybrid. SIEM with configurable aggregation into meaningful security intelligence (C.5.6.9 #19–20); alerts/notifications on business-rule and workflow thresholds (C.5.6.9 #21–22).
• AU-8 Time Stamps — DOES OIT. All critical system times synchronized (C.5.7.40).
• AU-9 Protection of Audit Information — DOES OIT. Audit information and audit tools protected from unauthorized access, modification, and deletion (C.5.7.41); role-based access to audit logs (C.5.6.9 #6).
• AU-11 Audit Record Retention — Hybrid. Organization-defined retention (C.5.7.42); [TBD] — minimum recommendation one year online, three years archive.
• AU-12 Audit Record Generation — DOES OIT. Automated audit trails for all system components (C.5.7.39); system-generated security audit trail (C.5.6.9 #17); SANS Information Logging Standard compliance (C.5.6.9 #18).
• AU-14 Session Audit — DOES OIT. Searchable log of all screens accessed by user (C.5.6.9 #7); sensitive-data screen access monitored and recorded (C.5.6.9 #5).

14.4 Assessment, Authorization, and Monitoring (CA)

• CA-2 Control Assessments — DOES. Independent assessment prior to ATO; annual reassessment.
• CA-3 Information Exchange — DOES. ISAs/MOUs per §11.
• CA-5 POA&M — DOES. Maintained as ypms/POAM.md.
• CA-6 Authorization — DOES. AO ATO decision.
• CA-7 Continuous Monitoring — Hybrid. See §15.
• CA-8 Penetration Testing — DOES commissions; OIT supports. At least annually and after major releases.
• CA-9 Internal System Connections — DOES OIT.

14.5 Configuration Management (CM)

• CM-2 Baseline Configuration — DOES OIT. Application baseline in the repo (Dockerfile / compose / IaC); DOES-approved tool/software list (source RFP C.5.6.13); IEEE 828-2012 alignment (source RFP §C.2 Item 8).
• CM-3 Configuration Change Control — Hybrid. DOES approves changes (C.5.6.13, C.5.6.17); 30-day advance notice for maintenance-window changes; NOC coordination.
• CM-4 Impact Analysis — DOES OIT. Required per C.5.8.12 before database design changes.
• CM-5 Access Restrictions for Change — DOES OIT.
• CM-6 Configuration Settings — DOES OIT. Admin-configurable security controls (C.5.6.7); certificate authority configuration (C.5.6.5); infrastructure configuration (C.5.6.6).
• CM-7 Least Functionality — DOES OIT.
• CM-8 System Component Inventory — DOES OIT. Comprehensive tool/software list (C.5.6.13).
• CM-9 Configuration Management Plan — DOES OIT. Delivered as ypms/CONFIGURATION_MANAGEMENT_PLAN.md (to be authored).
• CM-11 User-Installed Software — Hybrid. End-user installation prohibited on managed endpoints.

14.6 Contingency Planning (CP)

• CP-2 Contingency Plan — DOES OIT. Companion ypms/CONTINGENCY_PLAN.md. The 99.5% SLA (C.5.6.17) sets the recovery envelope; failover to remote site required (C.5.6.13).
• CP-3 Contingency Training — Hybrid.
• CP-4 Contingency Plan Testing — Hybrid. Annual tabletop plus functional test of failover.
• CP-6 Alternate Storage Site / CP-7 Alternate Processing Site — DOES OIT. Redundant tiers, multi-platform load distribution (C.5.6.18, C.5.6.29).
• CP-9 System Backup — DOES OIT. Azure Backup with encrypted geo-redundant storage; documented backup and restore procedures (source RFP C.5.8.14); daily-backup discipline retained (source RFP C.5.8.21) with tested restore drill.
• CP-10 System Recovery and Reconstitution — DOES OIT.

14.7 Identification and Authentication (IA)

• IA-2 Identification and Authentication (Organizational Users) — DOES OIT. Unique user ID (C.5.7.38); admin actions tied to individual identity (C.5.7.36).
• IA-2(1)/(2) MFA — DOES OIT. MFA required for staff and admin; RFP text (C.5.7.6) permits "unique identifier + shared secret answer" — this is insufficient by NIST SP 800-63B AAL2; SSP requires MFA above the RFP floor for privileged and staff users. See open question §17.G.
• IA-3 Device Identification and Authentication — Hybrid.
• IA-4 Identifier Management — DOES OIT. No re-issue of deleted IDs (C.5.7.47).
• IA-5 Authenticator Management — DOES OIT. Password establish/change (C.5.7.8); administrator reset with forced change on next login (C.5.7.12); expiry policy (C.5.7.13); password-change notification via email or SMS (C.5.7.14); policy for complexity/reuse/length/expiration (C.5.7.45); masked entry (C.5.7.46); FIPS 140-2 crypto for passwords in storage and transit (C.5.7.9); minimum 12-character alphanumeric ID (C.5.7.7).
• IA-6 Authenticator Feedback — DOES OIT.
• IA-7 Cryptographic Module Authentication — DOES OIT. FIPS 140-2 (C.5.7.9, RFP §C.2 Item 9).
• IA-8 Identification and Authentication (Non-Organizational Users) — DOES OIT. Youth and host authentication, including social-media login option (C.5.3.2) — see risk discussion in §17.D.
• IA-11 Re-authentication — DOES OIT. On session timeout (C.5.7.3); should be required on privilege elevation and sensitive-action (banking change, eligibility change, payroll approval) — SSP tailoring.
• IA-12 Identity Proofing — DOES OIT. [TBD] — IAL model for youth registrants (many are minors) requires deliberate design; social-media identity alone is insufficient for payroll enrollment.

14.8 Incident Response (IR)

• IR-1 Policy — DOES.
• IR-4 Incident Handling — Hybrid. Companion ypms/INCIDENT_RESPONSE_PLAN.md. DOES OIT IDS/IPS and application logs feed DC OCTO Sentinel (source RFP C.5.7.26, C.5.6.9 #19).
• IR-6 Incident Reporting — Hybrid. Immediate notification of unauthorized disclosure through DOES OIT → DC OCTO CISO; 24-hour internal disclosure report; 2-business-day remediation report. SLAs adopted from source RFP C.5.8.18–C.5.8.20 as internal DOES policy. Federal breach reporting on top per Privacy Act and any SSA/OSSE/CFSA agreement requirements.
• IR-8 Incident Response Plan — DOES.

14.9 Maintenance (MA)

• MA-2 through MA-6 — Hybrid / Inherited. Physical maintenance inherited from Azure Government. Application maintenance windows require 30-day advance notice to DC NOC (source RFP C.5.6.17 adopted as internal SLA).

14.10 Media Protection (MP)

• MP-2 through MP-7 — Inherited / Hybrid. No physical media in target architecture. Endpoint media controls inherited from DC OCTO endpoint program for DOES-managed devices.

14.11 Physical and Environmental Protection (PE)

• PE-1 through PE-20 — Inherited from Azure Government FedRAMP High authorization; Hybrid for DOES-managed endpoints.

14.12 Planning (PL)

• PL-2 System Security and Privacy Plan — This document.
• PL-4 Rules of Behavior — DOES. Companion ypms/RULES_OF_BEHAVIOR.md, with separate variants for staff, host employers, and youth/parent users.
• PL-8 Security and Privacy Architecture — DOES OIT. Architecture document per source RFP C.5.5.5 — tracked as YPMS-POAM-040.
• PL-10 Baseline Selection / PL-11 Baseline Tailoring — Documented in §2.3.

14.13 Program Management (PM)

• PM-1 through PM-32 — DOES / DC OCTO CISO Office. Inheritance documented in the DOES organization-wide security program plan [TBD].

14.14 Personnel Security (PS)

• PS-1 through PS-9 — Hybrid. DOES HR handles background checks and access agreements for DOES OIT staff and any contracted individual developers. DOES OIT maintains and reviews the roster of personnel with production data access at least quarterly, with additions and deletions tracked (source RFP C.5.8.16, C.5.8.17 adopted as internal policy).

14.15 PII Processing and Transparency (PT)

• PT-2 Authority to Process PII / PT-3 Purpose Specification — Documented via PIA.
• PT-4 Consent / PT-5 Privacy Notice — DOES. Notice designed for minors and parents where applicable.
• PT-6 System of Records Notice (SORN) — TBD — applicability review by DOES Privacy Officer.
• PT-7 Specific Categories of PII — Sensitive PII enumerated in §13.

14.16 Risk Assessment (RA)

• RA-2 Security Categorization — Documented in §2.
• RA-3 Risk Assessment — DOES.
• RA-5 Vulnerability Monitoring and Scanning — DOES OIT. Cyber-threat detection and remediation (C.5.7.52). Authenticated and unauthenticated scans at minimum monthly; container/image scans on push where applicable.
• RA-7 Risk Response — DOES. POA&M-driven.
• RA-10 Threat Hunting — Hybrid.

14.17 System and Services Acquisition (SA)

• SA-3 SDLC — DOES OIT. Agile SDLC matching OWC / DCYWP patterns; discipline adopted from source RFP C.5.2.
• SA-4 Acquisition Process — DOES. Applies to third-party components DOES procures (payroll vendor, LMS vendor, SaaS subcomponents).
• SA-8 Security and Privacy Engineering Principles — DOES OIT.
• SA-9 External System Services — DOES OIT. Governs payroll vendor, LMS vendor, DC MAR, social-media IdPs, and any SaaS subcomponents.
• SA-10 Developer Configuration Management / SA-11 Developer Testing and Evaluation — DOES OIT. Data-model deliverables per source RFP C.5.8.4–C.5.8.11; testing and UAT per source RFP §C.5.10.
• SA-15 Development Process, Standards, and Tools — DOES OIT.
• SA-22 Unsupported System Components — DOES OIT. Third-party dependencies tracked in SBOM with maintained upgrade path (source RFP C.5.6.13).

14.18 System and Communications Protection (SC)

• SC-5 Denial-of-Service Protection — DOES OIT.
• SC-7 Boundary Protection — DOES OIT. Trusted/transition/untrusted zones (C.5.7.23).
• SC-8 Transmission Confidentiality and Integrity — DOES OIT. Encryption in transit (source RFP C.5.7.25); source RFP C.5.6.15 says SSL, which is deprecated; SSP tailors this to TLS 1.2 minimum, TLS 1.3 preferred, FIPS-approved cipher suites.
• SC-10 Network Disconnect — DOES OIT.
• SC-12 / SC-13 Cryptographic Key Establishment and Use — DOES OIT. FIPS 140-3 cryptography (140-2 acceptable during deprecation window) via Azure Key Vault (Gov / HSM).
• SC-17 Public Key Infrastructure Certificates — DOES OIT. Certificate Authority configuration (C.5.6.5).
• SC-23 Session Authenticity — DOES OIT.
• SC-28 Protection of Information at Rest — DOES OIT. Encryption of all PII at rest (C.5.7.25); SSN masked/anonymized in display (C.5.7.50).
• SC-39 Process Isolation — Inherited.

14.19 System and Information Integrity (SI)

• SI-2 Flaw Remediation — DOES OIT. Cyber-threat remediation (source RFP C.5.7.52); DOES OIT patch cadence with failover-during-patching capability (source RFP C.5.6.13).
• SI-3 Malicious Code Protection — DOES OIT. Upload scanning for document uploads.
• SI-4 System Monitoring — DOES OIT. IDS/IPS with alerting (C.5.7.26); SIEM (C.5.6.9 #19–23); performance monitoring (C.5.6.22).
• SI-5 Security Alerts, Advisories, and Directives — DOES OIT.
• SI-7 Software, Firmware, and Information Integrity — DOES OIT.
• SI-10 Information Input Validation — DOES OIT. Character set, length, numerical range, format and content, trusted-source restriction (C.5.7.44); address verification (C.5.6.2); SSA-verified SSN (C.5.6.3.b); DC MAR address validation (C.5.6.3.d).
• SI-11 Error Handling — DOES OIT. Corrective information without adversary-exploitable disclosure (C.5.7.43); consistent error handling with clear messages, all errors logged (C.5.6.9 #2, #3).
• SI-12 Information Management and Retention — DOES.
• SI-16 Memory Protection — Inherited.

14.20 Supply Chain Risk Management (SR)

• SR-1 through SR-12 — Hybrid. CycloneDX SBOM generated per release in CI (YPMS-POAM-042); third-party dependencies reviewed and pinned; provenance for payroll and LMS vendors; comprehensive tool/software list (source RFP C.5.6.13).

---

15. Continuous Monitoring

The YPMS Continuous Monitoring Strategy will follow DOES CIO / DC OCTO CISO guidance and NIST SP 800-137. Anticipated cadence:

Activity	Frequency	Owner
Log stream to DC OCTO Sentinel	Continuous	DOES OIT → DC OCTO
Vulnerability scanning (authenticated + unauthenticated)	Monthly	DOES OIT
Personnel-with-data-access roster review	Quarterly	DOES ISSO
Configuration drift check (CIS Azure Foundations)	Weekly	DOES OIT
POA&M review	Monthly	DOES ISSO
Access recertification (privileged)	Quarterly	DOES OIT + ISSO
Access recertification (all users)	Annually	DOES OIT + ISSO
Backup + restore drill (daily backup, periodic restore)	Daily backup, annual full restore drill	DOES OIT
Contingency plan test	Annually (tabletop + functional element)	DOES OIT + ISSO
Independent control assessment	Annually	DOES-commissioned
Penetration test	Annually and after major release	DOES-commissioned
Availability performance report (99.5% SLA envelope)	Monthly	DOES OIT
SSP update	On material change; at least annually	DOES ISSO

Ongoing metrics reported to the AO: SLA achievement (99.5%), patch SLA adherence, MTTR for high/critical vulns, open POA&M aging, and count of unauthorized-disclosure notifications.

---

16. Plan Approval

Role	Name	Signature	Date
System Owner (DOES CIO)	Chris Tonjes
Information System Security Officer	Chris Tonjes
Business Owner (OYP)	[TBD]
DOES OIT Delivery Lead	[TBD]
Authorizing Official	Chris Tonjes (per §5 role-concentration note)

---

17. Appendices

Appendix A — Acronyms

AAL Authentication Assurance Level · AO Authorizing Official · APM Application Performance Monitoring · ATO Authorization to Operate · CFSA Child and Family Services Agency · CIS Center for Internet Security · CISO Chief Information Security Officer · COTS Commercial Off-the-Shelf · CP Contingency Plan · CRESP Career Ready Early Scholars Program · DC MAR DC Master Address Repository · DC OCTO DC Office of the Chief Technology Officer · DOES DC Department of Employment Services · FERPA Family Educational Rights and Privacy Act · FIPS Federal Information Processing Standards · FISMA Federal Information Security Modernization Act · FedRAMP Federal Risk and Authorization Management Program · HIPAA Health Insurance Portability and Accountability Act · HSIP High School Internship Program · IaaS Infrastructure-as-a-Service · IAL Identity Assurance Level · IAM Identity and Access Management · IDS/IPS Intrusion Detection/Prevention System · ISA Interconnection Security Agreement · ISSO Information System Security Officer · LDAP Lightweight Directory Access Protocol · LMS Learning Management System · MBSYEP Marion S. Barry Summer Youth Employment Program · MBYLI Marion Barry Youth Leadership Institute · MFA Multi-Factor Authentication · MTTR Mean Time to Remediate · NIST National Institute of Standards and Technology · NOC Network Operations Center · OCTO Office of the Chief Technology Officer · OIT Office of Information Technology · OSSE Office of the State Superintendent of Education · OYP Office of Youth Programs · PCI DSS Payment Card Industry Data Security Standard · PIA Privacy Impact Assessment · PII Personally Identifiable Information · POA&M Plan of Action and Milestones · SaaS Software-as-a-Service · SANS SysAdmin Audit Network Security · SDLC System Development Life Cycle · SIEM Security Information and Event Management · SIT Summer Intensive Training · SOC Security Operations Center · SORN System of Records Notice · SSA Social Security Administration · SSP System Security Plan · SYP School Year Program · UAT User Acceptance Test · WCAG Web Content Accessibility Guidelines · YPMS Youth Program Management System

Appendix B — References

• NIST SP 800-18 Rev. 1 — Guide for Developing Security Plans.
• NIST SP 800-37 Rev. 2 — Risk Management Framework.
• NIST SP 800-47 Rev. 1 — Managing the Security of Information Exchanges.
• NIST SP 800-53 Rev. 5 — Security and Privacy Controls.
• NIST SP 800-60 Vol. II — Guide for Mapping Types of Information.
• NIST SP 800-63-3 — Digital Identity Guidelines.
• NIST SP 800-137 — ISCM.
• NIST SP 800-171 Rev. 2 — CUI Protection.
• FIPS 199 / FIPS 200 / FIPS 140-2 (with FIPS 140-3 forward alignment).
• FERPA (20 USC §1232g).
• Privacy Act (5 USC §552a).
• SSA Electronic Information Exchange Security Requirements.
• DC OCTO IT Security Policy.
• DC Code Title 32 Chapter 2 Subchapters II and V.
• DC Code Title 4.
• IEEE 828-2012.
• PCI DSS.
• WCAG 2.1 AA / Section 508.
• SANS Information Logging Standard.

Appendix C — RFP Security Requirement → SSP / Control Traceability

Traceability for the 54 C.5.7 Security Requirements and the load-bearing items from C.5.6 and C.5.8.

RFP Ref	Requirement (abbreviated)	SSP Section / Control
C.5.7.1	External + internal role-based authN/authZ	§14.1 AC-2, AC-3; §14.7 IA-2, IA-8
C.5.7.2	Authorized users export data with designated file format, name, schedule, protocol, destination	§14.1 AC-6; §14.18 SC-8
C.5.7.3	Session timeout on inactivity, re-authentication required	§14.1 AC-11/AC-12; §14.7 IA-11
C.5.7.4	Auto-disable accounts after inactivity	§14.1 AC-2
C.5.7.5	Admin can enable/disable user access	§14.1 AC-2
C.5.7.6	Login = unique identifier + shared secret	§14.7 IA-2 (SSP tailors above this floor to require MFA for staff/admin)
C.5.7.7	12–64 alphanumeric user IDs	§14.1 AC-2; §14.7 IA-4
C.5.7.8	User-established and changeable passwords	§14.7 IA-5
C.5.7.9	FIPS 140-2 crypto for passwords in storage and transit	§14.7 IA-7; §14.18 SC-12/SC-13
C.5.7.10	Lockout after 5 failed attempts	§14.1 AC-7
C.5.7.11	Notification on access revocation	§14.1 AC-7
C.5.7.12	Admin password reset with forced change on login	§14.7 IA-5
C.5.7.13	Password expiration policy	§14.7 IA-5
C.5.7.14	Password-change notification by email or SMS	§14.7 IA-5
C.5.7.15	Capture user ID and timestamp on create/modify/delete	§14.3 AU-3
C.5.7.16	Authorized user view of record at specified point in time	§14.3 AU-14
C.5.7.17	Authorized user backdated transactions with reprocessing	§14.1 AC-6; §14.3 AU-3
C.5.7.18	Authorized user acts on behalf of customer	§14.1 AC-6; §14.3 AU-3
C.5.7.19	Customer profile view/update	§14.15 PT-2
C.5.7.20	Customer secure transactions from home page	§14.18 SC-8, SC-23
C.5.7.21	Authorized users view/add/modify records	§14.1 AC-3
C.5.7.22	Customer-profile relationships	§14.15 PT-2
C.5.7.23	Untrusted systems cannot reach trusted zones	§14.1 AC-4; §14.18 SC-7
C.5.7.24	Minimum Level 3 security across data lifecycle	§14 (see open question §17.A)
C.5.7.25	Encrypt all PII collected/processed/stored/transmitted	§14.18 SC-8, SC-28
C.5.7.26	IDS/IPS with alerts on compromise	§14.19 SI-4; §14.8 IR-4
C.5.7.27	Enforce authorizations per access control policies	§14.1 AC-3
C.5.7.28	Only admins view/change access rights	§14.1 AC-3, AC-6
C.5.7.29	Group + individual assignment via OCTO/DOES LDAP	§14.1 AC-2
C.5.7.30	LDAP compliance	§14.7 IA-2; §11
C.5.7.31	Real-time and scheduled access-right changes	§14.1 AC-3
C.5.7.32	RBAC over defined objects	§14.1 AC-6
C.5.7.33	One login per staff, role-mediated access	§14.1 AC-6
C.5.7.34	Admin maintains role-based security	§14.1 AC-6
C.5.7.35	Mobile-platform encryption/access/app-security	§14.1 AC-19
C.5.7.36	Auto-log all admin actions incl. account changes	§14.3 AU-2, AU-3
C.5.7.37	User notification before access granted	§14.1 AC-8
C.5.7.38	Unique user ID per user for traceability	§14.7 IA-4
C.5.7.39	Automated audit trails on root/admin, audit-log access, logon events, PII interactions, org-defined events	§14.3 AU-2, AU-12
C.5.7.40	Time synchronization	§14.3 AU-8
C.5.7.41	Protect audit info and audit tools	§14.3 AU-9
C.5.7.42	Retain audit trail per org-defined period	§14.3 AU-11
C.5.7.43	Error messages informative but not exploitable	§14.19 SI-11
C.5.7.44	Input validation and trusted-source restriction	§14.19 SI-10
C.5.7.45	Org-defined password policy (complexity/reuse/length/expiration)	§14.7 IA-5
C.5.7.46	Mask passwords on entry	§14.7 IA-6
C.5.7.47	No re-issue of deleted/previous user IDs	§14.1 AC-2; §14.7 IA-4
C.5.7.48	Audit records: what/when/where/source/outcome/identity	§14.3 AU-3
C.5.7.49	Audit records sufficient to reconstruct events	§14.3 AU-3
C.5.7.50	Mask/anonymize SSN	§14.18 SC-28; §13
C.5.7.51	NIST 800-53 compliance	§2.3; §14 (all)
C.5.7.52	Cyber-threat detection and remediation	§14.16 RA-5; §14.19 SI-2
C.5.7.53	DC OCTO IT policies compliance	§12.2; §14 (all)
C.5.7.54	Ethical security for emerging technologies (GenAI/ML/etc.)	§9.4; §14.17 SA-9
C.5.6.2	Data checks (address, age, residency)	§14.19 SI-10
C.5.6.3	External-application integrations (OSSE, CFSA, SSA, DC MAR, LMS, payroll)	§11
C.5.6.4	SSA Electronic Information Exchange compliance	§11; §12.1
C.5.6.5	Configure Certificate Authority	§14.18 SC-17
C.5.6.6	Configure infrastructure (DB, space, performance)	§14.5 CM-6
C.5.6.7	Configure security controls	§14.5 CM-6
C.5.6.8	Security approach per DC OCTO policies	§12.2; §14 (all)
C.5.6.9	Audit requirements (23-item list)	§14.3 AU-2 through AU-14
C.5.6.10	24-hour operability	§2.1 Availability
C.5.6.11	Modern browser support	§8.4
C.5.6.13	Failover to remote site during patching	§14.6 CP-6/CP-7; §14.5 CM-3
C.5.6.14	OCTO cloud coordination	§5; §9.2
C.5.6.15	SSL for confidential transmissions (SSP tailors to TLS 1.2+)	§14.18 SC-8
C.5.6.16	Hosted IaaS with DOES-approved security	§9.2
C.5.6.17	99.5% availability SLA, 30-day maintenance notice	§2.1 Availability; §14.9 MA
C.5.6.18	Redundant multi-tier architecture	§14.6 CP-6/CP-7
C.5.6.19	PCI DSS compliance	§2.3; §12.1
C.5.6.20	50%-per-year growth scaling	§8.3
C.5.6.29	Load distribution across hosting platforms	§14.6 CP-6/CP-7
C.5.6.30	Endpoints comply with DC OCTO policy	§14.1 AC-19
C.5.6.31	Scalable emerging-tech infrastructure	§9.4
C.5.6.32	Emerging-tech data remains in DOES domain	§9.4; §14.17 SA-9
C.5.8.14	Backup and restore procedures	§14.6 CP-9
C.5.8.15	APIs and web services secured	§14.18 SC-8; §14.19 SI-10
C.5.8.16	Personnel-with-data-access roster at project start	§14.14 PS
C.5.8.17	Quarterly personnel-with-data-access roster updates	§14.14 PS
C.5.8.18	Immediate unauthorized-disclosure notification	§14.8 IR-6
C.5.8.19	24-hour disclosure report	§14.8 IR-6
C.5.8.20	2-business-day remediation report	§14.8 IR-6
C.5.8.21	Daily backup delivered to DOES	§14.6 CP-9

Appendix D — Open Questions

Each item cross-references its POA&M ID in ypms/POAM.md.

A. What is "Level 3 security" in source RFP C.5.7.24 (YPMS-POAM-051)? Source RFP requires "a minimum of Level 3 security to all data" without defining Level 3. Two plausible readings: (1) internal maturity level, or (2) NIST SP 800-63 AAL/IAL Level 3. SSP treats it as the higher until DOES clarifies with the AO.

B. Youth age band typo (source RFP §C.3.1 "99 – 24 years old"). Correct in derived requirements. SSP uses program-appropriate ranges.

C. Social-media login for youth (YPMS-POAM-050) — risk acceptance required. Accepting social-media identity assertions for payroll-eligible minors is a live IAL question. Options: (1) social-media login accepted only for browsing / pre-application; (2) full identity proofing (Login.gov, SSA verification) before banking/payroll actions; (3) require parental co-authentication for under-18 registrants. SSP recommends option 2, with option 3 as a compensating control.

D. PCI DSS scope (YPMS-POAM-052). If no card processing occurs (payroll is ACH via third-party vendor), PCI scope is zero and this control set drops. Expected out of scope; confirm with OYP.

E. MFA above the source-RFP floor. Source RFP C.5.7.6 — "unique identifier + shared secret answer" — is not MFA. SSP tailors to require MFA for staff and admin (YPMS-POAM-030); question whether youth/host MFA is also required at first sensitive action.

F. Retention (YPMS-POAM-054). Align with DOES records schedule for OYP program records and audit logs (source RFP C.5.7.42).

G. Emergency health-record CSV path (YPMS-POAM-053). In-boundary steady state, or separate emergency-scoped extension with its own PIA? SSP recommends the latter to keep steady-state categorization from being dragged up by a dormant path.

H. FIPS 140-2 vs. FIPS 140-3 (YPMS-POAM-032). Source RFP cites 140-2 (which is sunset). SSP requires 140-3 where available and treats existing 140-2 validations as acceptable during the deprecation window.

I. IAL2-equivalent identity proofing before payroll (YPMS-POAM-033). Source RFP silent; SSP tailors to require proofing above social-media assertion for payroll-eligible actions. Feeds open question D.

Appendix E — Related Documents (companion, to be authored in ypms/)

• ypms/FIPS_199_MEMO.md
• ypms/NIST_800_53_CONTROL_MAPPING.md
• ypms/PRIVACY_IMPACT_ASSESSMENT.md
• ypms/INCIDENT_RESPONSE_PLAN.md
• ypms/CONTINGENCY_PLAN.md
• ypms/RULES_OF_BEHAVIOR.md (staff, host, youth/parent editions)
• ypms/POAM.md
• Architecture and Design document (DOES OIT deliverable; source RFP C.5.5.5)
• Configuration / Change Management Plan (DOES OIT deliverable; source RFP §C.5.12)
• DOES–OSSE Data Sharing Agreement (FERPA) [TBD]
• DOES–CFSA MOU [TBD]

---

End of draft v0.3 (in-house build reframe).