At MSTS, GRC work follows the NIST Risk Management Framework end to end. This means participating in the full lifecycle — not just one phase. Control selection starts from the applicable NIST 800-53 baseline (Moderate or High depending on system categorization), adjusted for the specific environment and DOE/NNSA overlays. Implementation documentation maps controls to the actual technical and procedural configurations in place. Assessment support involves collecting evidence, working with assessors, and documenting gaps where controls are not fully implemented. Authorization support means getting that documentation package into a state that can go in front of an Authorizing Official.
The federal environment at MSTS is not a standard commercial deployment — classified and unclassified systems have separate RMF boundaries, and controls must be applied and assessed within each boundary independently.
Existing security controls across endpoint and infrastructure are mapped to NIST Cybersecurity Framework categories. This provides a second lens on the control environment beyond the RMF baseline — showing where the organization sits across Identify, Protect, Detect, Respond, and Recover functions. The mapping surfaces coverage gaps that the 800-53 baseline alone may not highlight in operational terms.
Tenable Nessus is the primary vulnerability scanning tool. Findings from scan results are translated into POA&M entries — each item capturing the finding, affected systems, severity, responsible owner, remediation milestone dates, and current status. Managed 100+ CVE findings through this process: tracking remediation progress, following up with system owners, and closing entries when remediation evidence confirmed closure.
This is not just a spreadsheet exercise — open POA&M items represent real risk posture and feed directly into authorization decisions and continuous monitoring reporting. Accuracy and completeness matter.
Security risk assessments evaluate endpoint and infrastructure posture against federal security requirements. This includes reviewing system configurations, patch status, access controls, and logging coverage, then documenting findings using federal documentation standards. Risk findings are rated, tracked, and fed into the remediation pipeline or accepted with documented rationale where remediation is not feasible within the assessment window.
The security requirements at MSTS are set by DOE/NNSA. This is a regulated federal environment with compliance obligations that go beyond what a standard NIST implementation requires — site-specific directives, classification guidance, and operational security requirements layer on top of the RMF baseline. Compliance work means understanding those layers and ensuring controls, documentation, and processes satisfy all applicable requirements, not just the NIST minimum.
Audit preparation involves evidence collection, control verification, and documentation review. When an assessment or audit cycle approaches, the work is pulling together the artifacts that demonstrate control implementation: configuration screenshots, policy documents, access review logs, scan reports, and remediation evidence. Documentation quality directly affects audit outcomes — a well-implemented control that is poorly documented fails the same as one that was never implemented.
At BART, GRC contributions focused on security policy reviews, compliance documentation, and SOP centralization with the cybersecurity team. This included reviewing existing policies against current security baselines, updating documentation to reflect actual operational procedures, and consolidating SOPs that had been fragmented across teams and formats into a single accessible location.