RMFInsider

If your DoD system collects, stores, or processes personally identifiable information about individuals, three things happen in sequence: a Privacy Threshold Analysis (PTA) confirms PII is present and how sensitive it is, a Privacy Impact Assessment (PIA, filed on DD Form 2930) documents how that PII is protected, and the CNSSI 1253 Privacy Overlay adds a set of privacy controls to your security baseline in eMASS. The Component privacy office owns the PTA and PIA determinations and the System of Records Notice (SORN). The ISSO owns the overlay selection in eMASS, the implementation and evidence for the added controls, and the accuracy of the PII fields in the system record. Getting those ownership lines wrong is how a PIA sits unsigned for six months while the ISSO and the privacy officer each assume the other one is working it.

First: does the system actually have PII?

The PTA answers this. It is a short questionnaire (the format varies by Component; the Navy, Army, and Air Force privacy offices each publish their own, and DISA has one for its hosted systems) that asks whether the system collects information about individuals, what kind, from whom, whether it is retrieved by a personal identifier, and whether it is shared outside DoD. The ISSO or the program office fills in the technical facts; the privacy officer signs the determination.

Three practical outcomes:

• No PII. The PTA is retained as evidence, the eMASS PII indicator is set to No, and no PIA or overlay is required. Keep the signed PTA in the artifacts anyway; the SCA will ask how you know.
• PII, but only DoD workforce contact-type information (name, work email, work phone, rank, office). This is still PII. A PIA is generally still required under DoDI 5400.16, though the overlay impact level is Low and the added controls are modest.
• PII beyond workforce contact data (SSN, DoD ID number, date of birth, home address, medical, financial, biometric, dependents, or any information about members of the public). PIA required, SORN likely required, and the Privacy Overlay applies at Moderate or High.

A note on the DoD ID number (EDIPI): it is PII. I have been in more than one meeting where a program insisted their system had “no PII, just the EDIPI from the CAC.” The EDIPI uniquely identifies a person, which is the definition, and the privacy office will say so.

The PII Confidentiality Impact Level drives everything downstream

The Privacy Overlay (Attachment 6 to Appendix F of CNSSI 1253) does not apply as one block. It is split into Low, Moderate, and High tiers based on the PII Confidentiality Impact Level, plus a separate PHI overlay for protected health information. The impact level is determined using the factors in NIST SP 800-122: how identifiable the data is, how many records, how sensitive the fields are, the context of use, and the obligation to protect (statute, regulation, agreement). The privacy officer makes this determination; the ISSO supplies the record counts and field inventory that feed it.

That impact level is separate from the system’s C-I-A categorization, and this is where packages get confused. A system can be categorized Low-Low-Low for its mission function and still carry a High PII confidentiality impact level because it holds SSNs for 40,000 dependents. The overlay does not raise your CNSSI 1253 categorization; it adds and strengthens controls on top of whatever baseline the categorization produced.

What the Privacy Overlay actually adds

In the NIST SP 800-53 Revision 4 era, privacy controls lived in Appendix J as eight separate families (AP, AR, DI, DM, IP, SE, TR, UL), and the overlay pulled those in alongside enhancements to security controls. Under Revision 5, the Appendix J families were retired and the privacy controls were integrated into the main catalog: a new PT (PII Processing and Transparency) family, plus privacy-relevant controls and enhancements scattered through AC, AT, AU, CM, IR, MP, PL, PM, RA, SA, SC, and SI. Which version your overlay maps to depends on which 800-53 revision your eMASS instance and Component have adopted; as of 2026 the DoD transition to Rev 5 baselines is well along but not uniform, so check the control set eMASS actually loaded before writing implementation statements against the wrong revision.

Regardless of revision, the controls that generate real work are predictable:

• PT-2 / PT-3 (Rev 5) or AP-1 / AP-2 (Rev 4): documenting the legal authority to collect and the specific purposes. The evidence is the SORN and the PIA. The ISSO does not write these; the ISSO references them.
• PT-5 / TR-1: Privacy Act statements on every collection point. If the web form collects PII and has no Privacy Act statement, that is an Open finding and a very easy one for the assessor to spot.
• AC-3, AC-6, AC-21: least privilege and sharing restrictions specifically for PII fields. Expect to demonstrate role-based access that separates who can see the SSN from who can see the name.
• AU-2, AU-3, AU-12: auditing access to PII records, not just logins. The assessor will ask for a log showing who viewed a specific record.
• SC-8, SC-13, SC-28: encryption in transit and at rest using FIPS-validated modules. Rev 4 shops know this as the overlay pushing SC-28(1) into a Low baseline that would not otherwise have it.
• MP-6, SI-12: sanitization and retention aligned to the records schedule. The privacy office owns the schedule; the ISSO owns proving disposal happened.
• IR-8, IR-9 (Rev 5): breach response. DoD breach reporting to the Component privacy office and US-CERT runs on short clocks, and the IR plan must show the PII-specific path.

Applying the overlay in eMASS

The overlay is selected during RMF Step 2 alongside your baseline. In eMASS, the overlay options appear when you configure the control set for the system (the exact screen depends on your instance and on whether the system is on a Rev 4 or Rev 5 baseline), and selecting the Privacy Overlay at the correct impact level pulls the additional controls and enhancements into your Controls tab automatically. Two things go wrong here consistently.

First, the overlay gets selected at the wrong tier because the PTA was not finished when the ISSO built the baseline, so the ISSO guessed Low. When the privacy officer later determines Moderate, the control set changes after implementation statements were written, and you are back in Step 3 for a dozen controls. Sequence matters: get the PII impact level from the privacy officer before you lock the baseline, even if that means sending the PTA the same day you register the system.

Second, the PII fields in System Information are left inconsistent with the overlay. eMASS carries a PII indicator, a PIA status field, a PIA date, and a place to upload the signed DD Form 2930. If the overlay is applied but the PIA status says “Not Required,” the package reviewer will send it back before the SCA ever sees it. Fill them in together.

The PIA: DD Form 2930

DoDI 5400.16 governs the DoD PIA process, and DD Form 2930 is the form. It is not long, but every section has a specific owner. The program office and ISSO complete the system description, the data elements collected, the sources, the sharing, the retention, and the safeguards. That safeguards section is where the ISSO earns their keep: it should reference the actual controls (encryption at rest via a named FIPS-validated module, role-based access as documented in the SSP, audit logging of record access, and so on), not generic assurances. Assessors read the PIA and the SSP side by side, and the two must describe the same system.

Signatures typically flow from the program manager or ISO, through the Component privacy officer, to the Component CIO or delegated PIA approving official. Once approved, an unclassified PIA is published publicly on the Component’s privacy site, which is worth remembering when you write the system description: whatever you put in Section 1 will be on the internet with your program’s name on it.

PIAs are reviewed on a cycle (every three years in the guidance I have worked under, or sooner when the system changes how it handles PII). Adding a data element, a new sharing partner, or a new collection point reopens the PIA, and that change should surface in your security impact analysis so it does not get discovered at reauthorization.

Where the SORN fits

The Privacy Act of 1974 requires a System of Records Notice, published in the Federal Register, for any system that retrieves records about individuals by name or personal identifier. This is the privacy office’s document end to end; the ISSO does not draft or file it. What the ISSO does is confirm that the system is covered by a SORN (either an existing DoD-wide or Component SORN whose scope actually includes this system’s data, or a new one) and cite the SORN identifier in the PIA, the SSP, and the PT-family implementation statements. “Covered under DoD-wide SORN DHRA 06” is an implementation statement. “The privacy office handles that” is not.

The wry truth about SORNs: a new one takes months to publish because it requires Federal Register notice and a public comment period. If your program is collecting a new category of PII and nobody has started the SORN, the ATO can be technically ready long before the system is legally allowed to operate. I have watched a program discover this three weeks before their planned go-live. Ask the question in Step 1.

Who owns what: a working split

This is the division I put in the kickoff email for any system with PII, adjusted for local policy. It prevents the six-month unsigned PIA.

The ISSO owns

• Providing accurate technical facts for the PTA and PIA: data elements, record counts, storage locations, encryption, access model, interconnections.
• Selecting the Privacy Overlay at the impact level the privacy officer determined, in eMASS, at Step 2.
• Setting the PII indicator, PIA status and date, and uploading the signed DD 2930 in eMASS.
• Writing implementation statements and gathering evidence for every overlay control, and referencing the SORN and PIA where the control is documentary.
• Making sure the SSP, the PIA, and the eMASS system record describe the same system.
• Flagging any PII-related change through the SIA process so the PIA gets reopened on time.

The privacy officer owns

• The PTA determination and the PII Confidentiality Impact Level.
• Deciding whether a PIA is required, routing it for signature, and publishing it.
• SORN coverage: identifying an existing SORN or drafting and publishing a new one.
• Records retention schedule and disposition authority.
• Privacy Act statement wording and breach notification decisions.

Where the two meet is the assessment. The SCA will ask the ISSO questions the privacy officer knows the answers to, and ask the privacy officer questions about controls the ISSO implemented. Put both people in the kickoff and the outbriefs. A privacy officer who hears about the assessment from a finding in the SAR is a privacy officer who will not answer your email quickly next time.

The PTA, PIA, SORN reference, and overlay selection are line items on the same pre-submission list as the boundary diagram and the hardware baseline, and I check them in that order on every package with PII. If you want that list in the sequence I actually work it, with the privacy items already in place, the RMF Checklist is what I use on my own systems.