1. Purpose
These minimum standards serve as a supplement to the Information Resources Use and Security Policy (IRUSP) (https://security.utexas.edu/policies/irusp) and the Controlled Research Security Policy (CRSP) (https://security.utexas.edu/controlled-research). They establish the minimum security requirements for university research involving Controlled Unclassified Information (CUI), as defined by the NARA CUI Registry and incorporated into sponsored research agreements through DFARS 252.204-7012 and related federal acquisition regulations.
These standards use NIST SP 800-171 Revision 2 as the security baseline, supporting Cybersecurity Maturity Model Certification (CMMC) Level 2 assessment readiness. Parenthetical citations identify applicable or related Revision 2 security requirements. Additional UT and sponsor requirements, including implementation details and review frequencies beyond the baseline, also apply. Compliance with these requirements does not by itself constitute a complete security program; these standards must be integrated into the System Security Plan (SSP) for each covered environment.
ISO is responsible for verifying compliance for all standards listed below.
2. Scope
These standards apply to all systems, endpoints, media, and personnel involved in accessing, processing, storing, or transmitting CUI in connection with U. T. Austin sponsored research, across three defined use cases (Section 4). They do not apply to research data that does not meet the definition of CUI; such data remains governed by the IRUSP and the university Minimum Security Standards (https://security.utexas.edu/content/min-security-standards).
3. Audience/Roles
Principal Investigators and research team members working with CUI; IT owners, custodians, and system administrators supporting controlled research; the Controlled Research Support Program (CRSP) enclave team; and staff of the Information Security Office (ISO), Research Security Office (RSO), and Office of Research Support and Compliance (ORSC). Accountability for each control family is defined in the CRSP standards (https://security.utexas.edu/controlled-research).
4. Use Cases
Column applicability in Section 5 is determined by where CUI is stored and processed. A single project may span more than one use case; where it does, the most restrictive applicable requirement must be applied. If a control is not applicable for a specific project, it must be documented in the SSP.
CUI is not stored or processed locally on a UT-managed device or network.
CUI is not stored or processed on any UT-managed device or within the UT network. Researchers access CUI only within an environment maintained by an external party (e.g., UT-administered GCC High, Texas Advanced Computing Center's Protected Data Service (https://tacc.utexas.edu/about/security-and-compliance), a sponsor-operated enclave, a federal system, or another institution's authorized environment). UT obligations are limited to personnel controls (training, screening, authorization), the managed access endpoint, the access path, and incident and transfer coordination.
Endpoints interacting with CUI data in this way should be managed according to the Minimum Security Standard for Systems: https://security.utexas.edu/content/min-security-standards/systems
CUI Processed or Stored Locally.
CUI is processed or stored on UT-managed systems or on other UT infrastructure. The full set of requirements applies to the environment and assets.
5. Minimum Standards
How to use this table:
- The Standard column defines mandatory outcomes, scope, timeframes, and approvals. The role columns explain the actions and evidence needed to meet each requirement.
- Role actions apply to in-scope assets and activities. Document inherited provider safeguards and any non-applicable requirement in the SSP. A blank cell or dash means no specific action is assigned to that role; it does not waive the standard.
5.1 Governance and Security Planning
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.1.1 | Obtain UT authorization and identify applicable sponsor and security requirements before beginning work with CUI. (Additional UT/sponsor requirement.) | Identify sponsor terms and required TCPs. Save the agreement and TCP in UTRMS. | Confirm the proposed environment meets project requirements before enabling access. | Review project safeguards and record any gaps to resolve. | Submit project information and obtain required approvals from OVPR before work begins. |
| 5.1.2 | Maintain and periodically update the SSP describing the system boundary, operating environment, security controls, and connections. Maintain corrective action plans for identified deficiencies. (3.12.4, 3.12.2) | Keep the project TCP updated. | Keep the project inventory and POA&M current in Isora. | Review project controls annually, track findings in Isora, and verify fixes before closing them. | Review the SSP and POA&M annually and after significant changes. Prioritize and remedy fixes. |
| 5.1.3 | Complete required policy acknowledgments before CUI access and renew them as required by UT. (Additional UT requirement.) | Assign policy acknowledgments with initial and annual training. | Check training and AUP records before granting or continuing access. | Check completion records and follow up on overdue acknowledgments. | Complete policy acknowledgment, CRSP training, and the AUP before access and annually. |
| 5.1.4 | Obtain an approved UT security exception before deviating from this standard. (Additional UT requirement.) | Identify sponsor restrictions affecting the request. | Submit the request with the PI through Isora: https://isora.security.utexas.edu/newui/exceptions-register. Include the reason, scope, duration, safeguards, and risks. | Review requests and record decisions, conditions, and expiration dates. | Explain the research need and submit the request with CRSP/local IT before making the change. |
5.2 Security Awareness and Training
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.2.1 | Ensure managers, administrators, and users understand applicable security risks, policies, and procedures, including how to recognize and report insider threats. (3.2.1, 3.2.3) | Assign CUI training in UT Learn before access and annually. | Check training completion before enabling access. | Approve training content, keep completion records, and follow up on overdue training. Check project public sites for accidental CUI disclosure. | Complete assigned training before access and annually. Obtain required review before public release and report accidental disclosure. |
| 5.2.2 | Train personnel to perform their assigned security duties. (3.2.2) | Assign role training and check completion before security duties begin and annually. | Define training for administrators, responders, and developers. Update it when duties change and keep completion records. | Complete training for assigned security duties before starting them and annually. |
5.3 Accounts and Access Control
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.3.1 | Identify users, processes acting for users, and devices. Prevent identifier reuse for the defined period. (3.5.1, 3.5.5) | Issue approved UT EID, GCC High, process, and device identifiers. Follow UT naming rules, record project associations, prohibit shared accounts, and do not reuse identifiers. | Check account and device records for shared, reused, or unauthorized identifiers. | Use your assigned account, provide project details for requests, and do not share credentials. | |
| 5.3.2 | Disable identifiers after the defined period of inactivity. (3.5.6) | Use approved account-change procedures and track approvals. Disable accounts after 90 inactive days or sooner when access is no longer needed, including EIDs, AD accounts, and any cloud platform accounts. | Check for inactive or unauthorized accounts and track their removal. | Follow UT HR procedures. Notify CRSP/ISO within 24 hours of personnel or access-need changes; provide the information needed to meet 5.13.2. | |
| 5.3.3 | Limit system access to authorized users, processes, and devices, and allow only their authorized functions. (3.1.1, 3.1.2) | Set access based on PI-approved duties and need-to-know. Apply it across system components and keep the approval record. | Maintain a list of HR-approved users associated with each research project. | Approve each person’s duties and access level. Report changes to CRSP/local IT. | |
| 5.3.4 | Separate sensitive duties and grant only necessary privileges. Use ordinary accounts for nonsecurity work, prevent ordinary users from performing privileged functions, and log privileged activity. (3.1.4–3.1.7) | Create separate admin accounts under MSS for Systems 4.5.14. Require independent approval, block unauthorized privileged functions, log privileged activity, and review access at least every 12 months. | Check admin-account approvals and annual access reviews. Track exceptions and needed fixes. | Use ordinary accounts for research. Explain the need for admin access and submit requests to CRSP/local IT; do not approve your own request. |
5.4 Authentication and Credentials
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.4.1 | Verify user, process, and device identities before access. Require MFA for privileged local/network access and ordinary network access. Network authentication must prevent reuse of captured sign-in messages. (3.5.2–3.5.4) | Apply the UT authentication profile. Require MFA for all CUI access, prohibit SMS-only MFA, and test that captured sign-in messages cannot be reused. | Enroll in approved MFA. Report lost factors, suspected compromise, and unexpected prompts. | ||
| 5.4.2 | Enforce password complexity, required character changes, and password-history rules. Require immediate replacement of temporary passwords and cryptographically protect stored and transmitted passwords. (3.5.7–3.5.10) | Apply IRUSP Standard 15 and MSS for Systems 4.5.13. Block common passwords, set password-history rules, change defaults before first use, and replace compromised passwords immediately. Revoke compromised credentials or credentials no longer authorized after personnel changes. See: https://security.utexas.edu/policies/irusp#standard15 | Use approved password/reset methods. Replace temporary passwords immediately, protect credentials, and report suspected compromise. | ||
| 5.4.3 | Hide authentication information during entry, such as by masking passwords. (3.5.11) | Enable password masking and check login, reset, and support screens. Record any exceptions. | Keep credentials out of screenshots, demonstrations, and support requests. |
5.5 Device and System Security
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.5.1 | Use only UT-approved, managed devices that meet this standard to access CUI. | Approve and enroll devices before access to CUI data. Record each device and assigned user in Isora; enforce the university-issued/managed-device rule unless the sponsor specifies otherwise. | Use only your assigned UT-approved device. Do not use personal or unmanaged devices; request approval before adding equipment. | ||
| 5.5.2 | Require full-disk encryption on systems storing or processing CUI, using UT-approved methods. (UT implementation requirement supporting 3.13.11 and 3.13.16.) | Enable approved full-disk encryption. Record the module, version, FIPS certificate, operating mode, and encryption status in the SSP. See: https://security.utexas.edu/policies/encryption | Do not disable encryption or export recovery keys. | ||
| 5.5.3 | Lock inactive sessions and conceal displayed information. Automatically end user sessions under defined conditions and network connections at session end or after defined inactivity. (3.1.10, 3.1.11, 3.13.9) | Set locks to 15 minutes or less, user-session termination to 24 idle hours or less, and network disconnects to 15 idle minutes or session end. Test the settings under MSS for Systems 4.4.3. | Lock devices when unattended and sign out when finished. | ||
| 5.5.4 | Limit repeated unsuccessful sign-in attempts. (3.1.8) | Lock accounts for at least 15 minutes after five failed attempts within five minutes. Notify administrators and test lockout and recovery. | Report unexpected lockouts and use approved account recovery. | ||
| 5.5.5 | Provide malicious-software protection at designated system locations and keep it updated. Scan systems periodically and external files in real time when downloaded, opened, or executed. (3.14.2, 3.14.4, 3.14.5) | Deploy UT Microsoft Defender (see MSS for Systems 4.3.1–4.3.4). Apply protection updates as released, enable real-time scanning, and run full scans at least weekly. | Keep devices available for updates and scans. Report alerts and do not disable protection. | ||
| 5.5.6 | Identify, report, and correct system flaws promptly. (3.14.1) | Apply software and firmware updates according to UT standards – see MSS for Systems 4.5.2–4.5.3, 4.7.2–4.7.3, and the VMP: https://security.utexas.edu/vmp. Use enterprise management, verify installation, and send patch results to Splunk. Review results in the UT Dept. Scorecards. Replace or isolate unsupported components. | Set project priorities, arrange downtime, and confirm fixes are complete. Report equipment or software that cannot be updated. | ||
| 5.5.7 | Display privacy and security notices consistent with applicable CUI requirements. (3.1.9) | Deploy the approved UT CUI banner through endpoint management – similar to MSS for Systems 4.5.10. Users must click-through the acknowledgement before accessing a device. | Read, acknowledge, and follow the notice. | ||
| 5.5.8 | Enforce approved security settings, enable only necessary system functions and services, and prevent split tunneling during remote access. (3.4.2, 3.4.6, 3.4.7, 3.13.7) | Apply approved ISO hardening guidance for devices where CUI is stored/processed (in development). Use the most restrictive settings compatible with operations - disable unnecessary services and block split tunneling. For systems that only access CUI via a remote platform, see MSS for Systems 4.5.1–4.5.5. See: https://security.utexas.edu/admin | Track compliance using benchmark scans. Record gaps and follow up on fixes. | Request needed functions through CRSP/local IT. Do not change security settings or create alternate network paths. |
5.6 CUI Storage and Cryptographic Protection
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.6.1 | Keep CUI within SSP-approved platforms, systems, and locations. Remote-only access must not create local CUI copies. | Maintain connection and processing agreements and identify sponsor restrictions. | For devices accessing CUI data ONLY through remote access to a managed platform: block downloads, local copies, printing to file, synchronization, file/clipboard redirection, and persistent caches. Apply the approved hardening profile and media restrictions. | Check external-system safeguards and record gaps to resolve. | Use approved CUI locations, systems, and transfer methods. Obtain approval before storing/processing CUI outside of approved platforms, equipment, or locations. |
| 5.6.2 | Protect stored CUI, including backups, from unauthorized disclosure. Use FIPS-validated cryptography whenever encryption provides that protection. (3.13.11, 3.13.16, 3.8.9) | Encrypt CUI storage and backups using FIPS-validated modules in approved modes. Keep validation certificates and settings in the SSP. For hosted services, confirm the specific storage/backup protections and document what UT relies on. See MSS for Systems 4.5.7. | Identify all CUI and backup locations. Use only approved storage. | ||
| 5.6.3 | Protect CUI during transmission using FIPS-validated encryption unless alternative physical safeguards protect it. Protect communications sessions against impersonation and session hijacking. (3.13.8, 3.13.11, 3.13.15) | Use FIPS-validated encryption, TLS 1.2 or higher or an approved equivalent, and certificate/host-key checks. Record methods and responsibilities in the SSP.
| Use approved transfer methods and recipients. Do not bypass certificate warnings. | ||
| 5.6.4 | Establish and manage the cryptographic keys used to protect CUI. (3.13.10) | Document who manages keys and how they are created, distributed, stored, accessed, rotated, and destroyed. Document cloud platform processes (e.g., GCC High) in the SSP. | Protect keys and other credentials. Report loss or compromise to CRSP/local IT. | ||
| 5.6.5 | Prevent shared system resources from exposing information through unauthorized or unintended transfers. (3.13.4) | Separate project processes and sessions. Clear shared memory, temporary storage, and caches as needed. Document UT-managed processes and cloud platform processes (e.g., GCC High) in the SSP. | Use assigned project storage and workspaces. Report unexpected access to another project’s data. |
5.7 Network Security and Communications
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.7.1 | Monitor, control, and protect communications at external and key internal boundaries. Deny traffic by default, allow approved traffic, and separate public-facing components from internal networks. (3.13.1, 3.13.5, 3.13.6) | Configure approved VRF/firewall rules and device admission (access should be limited to project-affiliated UT-approved devices affiliated with teh project in Isora). Separate public-facing components from internal networks. Track networking requests, approvals, and finalized rules; review rules at least annually and project rules quarterly. Confirm cloud platform (e.g., GHH High) configurations are compliant procedures. Document controls in SSP. | Monitor network events in Splunk and record investigations and response actions. | Identify needed equipment and network connections. Request approval before changes. | |
| 5.7.2 | Monitor and control remote access through managed access points and encrypted sessions. Authorize remote privileged commands and access to security-sensitive information. (3.1.12–3.1.15) | Set up the approved VPN or gateway (decision needed?) with MFA, encryption, logging, and monitoring. Track access requests/approval, including separate approval for privileged commands and security information. | Review remote-access events in Splunk and investigate suspicious activity. | Request remote access through CRSP. Use only the approved method. | |
| 5.7.3 | Approve wireless connections before use and protect them with authentication and encryption. (3.1.16, 3.1.17) | Track wireless access requests/approvals and apply approved authenticated, encrypted profiles. Connect local CUI wireless access through the project VRF and use the same approved-device controls listed in 5.7.1; disable unneeded wireless functions. | Use approved wireless connections. Request review before adding locations or equipment. | ||
| 5.7.4 | Control CUI movement according to approved authorizations. Review and control CUI posted or processed on publicly accessible systems. (3.1.3, 3.1.22) | Apply approved VRF/firewall and Purview DLP rules where available. For remote-only access, block local copies and unauthorized sharing under 5.6.1. | Check transfer controls and public sites for unauthorized CUI. Investigate alerts and track fixes. | Obtain approval before changing collaborators, destinations, or transfer methods. | |
| 5.7.5 | Prevent remote activation of collaboration devices and indicate when they are in use. Control and monitor mobile code, such as scripts, and internet-based voice services (VoIP). (3.13.12–3.13.14) | Disable remote camera/microphone activation and enable in-use indicators. Set approved browser, Office, PDF, and VoIP restrictions; monitor scripts, macros, voice services, and prohibited connections. | Use approved collaboration and voice tools. Request approval for restricted scripts or macros. |
5.8 Media and Mobile Device Protection
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.8.1 | Control removable-media use, restrict portable storage on external systems, and prohibit portable storage devices without an identifiable owner. (3.8.7, 3.8.8, 3.1.21) | Allow only UT-owned, inventoried, approved media with an identified owner. Enforce device/port restrictions, including limits on use with external systems; block local CUI media for remote-only access. | Request approval before connecting media. Do not use personal or unidentified drives; keep local CUI media in approved campus spaces. | ||
| 5.8.2 | Secure paper and digital CUI media, restrict access to authorized users, apply required markings, and track custody during transport. Encrypt digital media during transport unless alternative physical safeguards protect it. (3.8.1, 3.8.2, 3.8.4–3.8.6) | Apply approved marking, storage, access, and transport procedures. Encrypt digital media during transport and keep custody records.
| Mark and secure media, verify recipients, and record custody. Do not remove CUI from approved campus spaces. | ||
| 5.8.3 | Sanitize or destroy media containing CUI before disposal or release for reuse. (3.8.3) | See https://security.utexas.edu/policies/irusp - 11.71, 11.72, and 11.73. Record asset, method, verification, custody, and disposition; include instrument storage and access endpoints. Do not send systems storing/processing CUI-dataequipment to surplus or off-campus repair. | Arrange disposal, reuse, or repair through CRSP/local IT. Do not release equipment independently. | ||
| 5.8.4 | Control mobile-device (e.g., smartphones, tablets, e-readers, laptops, and portable wireless platforms ) connections and encrypt CUI stored on mobile devices and mobile computing platforms. (3.1.18, 3.1.19) | Approve and inventory mobile devices; enroll them in UT management and enable encryption and remote wipe. | Use assigned approved mobile devices. Keep devices holding local CUI in designated campus spaces and promptly report loss or theft. |
5.9 Audit Logging and Security Monitoring
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.9.1 | Create and retain logs sufficient to monitor, investigate, and report unauthorized activity and trace actions to individual users. Review and update the events logged. (3.3.1–3.3.3) | Log authentication, CUI access/transfers, privileged activity, account/group changes, configuration changes, and export/print events. Include time, location, source, outcome, and identity; see MSS for Systems 4.6.1 and 4.6.3–4.6.4. | Approve events and retention periods. Review event selections annually and after significant changes; record coverage gaps. | Confirm project logging coverage. Use individual accounts and report application or data-flow changes. | |
| 5.9.2 | Protect logs and logging tools from unauthorized access, changes, and deletion. Restrict logging administration to designated privileged users. (3.3.8, 3.3.9) | Send logs to ISO-managed Splunk and check delivery, including cloud platforms (e.g., GCC High). | Restrict logging administration to designated staff. Protect logs and tools, apply institutional retention rules, and check access permissions. | Confirm project log protections are documented. Do not alter logs or share investigation information without approval. | |
| 5.9.3 | Alert when logging fails. Correlate log review, analysis, and reporting, and provide filtering, summarization, and reporting tools for investigations. (3.3.4–3.3.6) | Fix logging failures and confirm delivery has resumed. Track notifications and fixes (e.g., ET ServiceNow). | Configure prompt failure alerts. Review related logs together at least weekly and after significant events; use Splunk searches and reports for investigations under MSS for Systems 4.6.2. Record reviews and follow-up. | Help investigate logging gaps and confirm they are resolved. Keep devices available for repair. | |
| 5.9.4 | Synchronize system clocks with a trusted time source to produce reliable log timestamps. (3.3.7) | Set managed time synchronization. Use UTC or a fixed UTC offset with timestamps accurate to one second or finer; check that system and provider logs can be matched. | Do not change managed time settings. Report incorrect instrument times. | ||
| 5.9.5 | Monitor systems and incoming/outgoing traffic for attacks and unauthorized use. Review security alerts and advisories and take appropriate action. (3.14.3, 3.14.6, 3.14.7) | Send Defender, Nessus, Tanium, network-tool results, and UT-approved cloud platforms (e.g., GCC High) to Splunk. Apply fixes when security alerts/issues are identified. | Monitor events and authoritative advisories, investigate alerts, and record actions. Restrict accounts or quarantine devices under approved response procedures. | Report suspicious activity promptly and follow containment instructions. |
5.10 Configuration and Change Management
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.10.1 | Maintain baseline configurations covering hardware, software, firmware, and documentation throughout each system’s life. (3.4.1) See: https://security.utexas.edu/admin | Apply approved hardening baselines. Note missing or mis-configured controls and address when identified. | Develop hardening baselines for CUI systems. Track compliance with baselines. Review at least annually and update after significant changes; keep versions and review records. | Check that baselines cover project needs. Report equipment changes and instrument limitations. | |
| 5.10.2 | Maintain a current inventory of system hardware, software, firmware, and documentation throughout the system life cycle. (3.4.1) | Document project inventory in Isora on a project-specific inventory sheet using the naming convention of DEPT-LastName-PI-CUI (e.g., INFS-HU-PI-CUI). Include all systems, locations, CUI scope. Link hosted services to the SSP and review quarterly. See instructions for documenting CUI assets: https://cloud.wikis.utexas.edu/wiki/spaces/ISO/pages/42031931/Isora#Controlled-Research-Assets-(e.g.%2C-CUI) | Check inventory accuracy monthly and report additions, removals, or changes. For remote-only access, identify access devices and hosted CUI locations. | ||
| 5.10.3 | Review, approve or reject, and record system changes; assess security impacts before implementation and restrict who can make changes. Block unauthorized software and control and monitor user installations. (3.4.3–3.4.5, 3.4.8, 3.4.9) | Use CRSP change control and MSS for Systems 4.2.1–4.2.2. Review security impacts, approve/reject changes, test them, and keep records. Restrict change access and enforce the approved-software allowlist through enterprise management. | Request changes and software before installation. Arrange testing and downtime; do not bypass restrictions. |
5.11 System Maintenance
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.11.1 | Perform system maintenance using controlled tools, methods, and personnel. Supervise maintainers lacking access authorization, sanitize equipment before off-site maintenance, and scan diagnostic/test media before use. (3.7.1–3.7.4, 3.7.6) | Review, approve, and track maintenance tools, personnel, and work. For tools/personnel with no approved access to CUI data, supervise maintenance and remove any temporary access after maintenance is complete. Sanitize equipment before it is shipped or retain CUI-bearing parts and send sanitized replacements. Track requests (e.g., ET ServiceNow). | Keep a list of any approved maintenance personnel. Arrange visits, repairs, surplus, and vendor-media use through CRSP/local IT; provide qualified escorts when maintenance is required in a space where CUI is stored/processed. | ||
| 5.11.2 | Require MFA for remote maintenance over external networks and disconnect sessions when maintenance is complete. (3.7.5) | Approve support sessions and use encrypted tools with MFA, logging, and monitoring. Disconnect immediately after work and remove temporary vendor access. | Request vendor support through CRSP. Do not enable persistent vendor access. |
5.12 Physical Security and Alternate Work Sites
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.12.1 | Restrict physical access to authorized people, escort and monitor visitors, and control keys, badges, and other access devices. (3.10.1, 3.10.3, 3.10.5) | Coordinate approved visits, escorts, keys, and badges. Remove physical access within one business day of separation or role change and record completion; See MSS for Controlled Research 5.13.2. | Keep physical-access logs. Review access lists at least every 12 months and after personnel changes; check applicable visitor safeguards for remote workspaces. | Approve access changes and keep lists current. Notify ISO/facilities, escort visitors as assigned, prevent tailgating, and report lost keys/badges. | |
| 5.12.2 | Protect and monitor facilities and supporting infrastructure, and maintain physical-access logs. (3.10.2, 3.10.4) | Secure printers and coordinate access restrictions for CUI rooms and infrastructure, including transmission lines. | Facilities: Operate BACS readers/cameras for designated rooms and wiring closets. ISO: Review logs at least every 45 days and after significant events; record reviews and decide which safeguards apply to remote workspaces. | Confirm room monitoring and reviews are covered. Use approved spaces, prevent unauthorized viewing, and report concerns. | |
| 5.12.3 | Apply safeguards to protect CUI at alternate work sites. (3.10.6) | Identify sponsor restrictions on the proposed work site. | Apply managed-device and remote-access protections under MSS for Systems. Needs additional ISO review. | Review workspace safeguards before PI authorization and record the review. | Use alternate sites only for remote-only CUI access. Obtain approval, use a managed device, protect screen privacy, lock unattended devices, and document safeguards in the SSP. Keep local CUI in approved campus spaces and follow UT travel procedures. |
5.13 Personnel Security
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.13.1 | Screen individuals before granting access to systems containing CUI. (3.9.1) | Review screening at hiring and at least annually, and after significant incidents or role changes. Apply required citizenship/export restrictions and keep screening records protected. | Enable access after screening and approvals are confirmed. K | Complete required screening, provide personnel information, and report relevant changes. | |
| 5.13.2 | Remove or adjust access and recover security-related property as needed to protect CUI during and after personnel terminations and transfers. (3.9.2) | Disable system access within four hours of termination notification and revoke credentials. Review access after transfers; coordinate BACS removal under 5.12.1 and record completion and property returns. | Notify CRSP promptly, approve access changes, and arrange return of devices, badges, keys, and tokens. |
5.14 Incident Response
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.14.1 | Maintain the ability to prepare for, detect, analyze, contain, and recover from incidents and support affected users. Track, document, and report incidents to designated internal and external officials. (3.6.1, 3.6.2) | Identify sponsor reporting duties and coordinate reports with ISO, including applicable 72-hour DFARS reporting. | Carry out directed response actions. Keep provider contacts current and retrieve needed logs and evidence. | Receive reports at security@utexas.edu and lead incident handling. Track incidents and coordinate required external reports with RSO. | Report suspected or confirmed incidents immediately to security@utexas.edu. Preserve evidence and follow instructions; coordinate external reporting through ISO/RSO. |
| 5.14.2 | Train personnel to carry out their assigned incident-response duties. (3.2.2; supports 3.6.1) | Assign training within 10 days for personnel assuming an IR role (privileged users), within 30 days for others, and annually thereafter. | Complete assigned training within the required period and keep confirmation. | Review training content and completion records. Track and enforce compliance with assigned training. | Complete assigned training within the required period and keep confirmation. |
| 5.14.3 | Test the incident-response capability for the CUI environment. (3.6.3) | Join exercises, provide technical information, and complete assigned fixes. | Maintain and protect the Incident Response Plan. Review it annually and test at least every 12 months; keep exercise results and follow up on fixes. | Keep project contacts current, join assigned exercises, and complete corrective actions. |
5.15 Risk Management and Security Assessment
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.15.1 | Periodically assess how systems handling CUI could put UT operations, reputation, assets, or people at risk. (3.11.1) | Provide system and vulnerability information for risk reviews. Complete assigned fixes. | Assess risks in Isora annually and after significant changes. Record decisions to accept, reduce, transfer, or avoid risks; update the SSP, POA&M and review the risk register quarterly. | Report project risks, explain research impacts, and complete assigned actions. | |
| 5.15.2 | Scan systems and applications periodically and when newly identified vulnerabilities may affect them. Fix vulnerabilities according to their assessed risk. (3.11.2, 3.11.3) | Deploy required vuln management tools (Nessus agents and authenticated scans); verify scan coverage and current signatures under MSS for Systems 4.7.1–4.7.3. Apply fixes within VMP deadlines. See https://security.utexas.edu/vmp. | Check scan coverage and overdue findings. Verify fixes using scan and patch results. Track compliance on Dept Scorecards. | Provide resources and arrange downtime for fixes. Confirm assigned actions are complete. | |
| 5.15.3 | Periodically assess control effectiveness, monitor controls on an ongoing basis, and carry out corrective action plans for identified weaknesses. (3.12.1–3.12.3) | Provide control and monitoring information for reviews. Complete assigned fixes. | GRC: Assess controls at least every 12 months in Isora. Record findings in the SSP-A/POA&M, monitor progress, and verify fixes before closure. | Review results, set priorities, provide resources, and complete assigned actions. | |
| 5.15.4 | Document and review security responsibilities and conditions for CUI exchanges with other systems. (Additional UT requirement; supports 3.1.20 and 3.12.4.) | Document connections, safeguards, and responsibilities in an ISA, MOU/MOA, SLA, or equivalent agreement and the SSP. Keep approvals and review agreements at least every 12 months. | Identify exchange partners and project needs. Obtain the agreement before exchange and join its annual review. |
5.16 External Services and Vendor Security
| # | Standard NIST SP 800-171 Rev. 2 | OVPR What to do | ET CRSP/Local IT What to do | ISO What to do | PI / Research Team What to do |
|---|---|---|---|---|---|
| 5.16.1 | Verify external systems meet applicable security requirements before use, and control their connections and use. (3.1.20) | Identify sponsor restrictions and required data-use agreements. | Set up approved connections and block unapproved services/devices. Document which safeguards UT and the provider manage. Confirm cloud services meet the required FedRAMP Moderate-or-higher authorization and other providers meet NIST SP 800-171 requirements. | Review the service’s security safeguards and record approval conditions. | Request approval before using an external service or changing a connection. |
| 5.16.2 | Review vendor security risks before granting CUI access and periodically thereafter. Include applicable security and sponsor requirements in vendor agreements. (3.1.20, 3.11.1) See: https://security.utexas.edu/risk/appreg | Ensure vendor agreements include required sponsor and DFARS terms. | Identify the vendor’s access needs. Provide technical details for review and report changes. | Complete the procurement security review. Record approval conditions and reassess risks when services or access change. | Submit vendor requests before purchase or access. Report changes or security concerns. |
| 5.16.3 | Use secure system designs and development practices, and separate ordinary user functions from system administration. (3.13.2, 3.13.3) See: https://security.utexas.edu/content/min-security-standards/app-dev-admin | Review designs, research code, and integrations before use. Separate ordinary and admin functions, apply supporting UT standards and MSS for Systems 4.10.1, and keep review and acceptance results. | Involve CRSP before developing or acquiring systems. Describe research needs and help confirm the system meets them. |
6. Non-Compliance and Exceptions
If any requirement in this standard cannot be met, a security exception must be requested and approved before the deviation is implemented, including justification, scope, duration, proposed compensating controls, and an assessment of risk to CUI (https://forms.security.utexas.edu/misc/exception). Emergency exceptions must be documented and reviewed retroactively.
Non-compliance may result in revocation of system or network access, suspension of the affected research activity, notification of supervisors and sponsors, and reporting to the Office of Internal Audit. Exceptions affecting a CMMC assessment scope must also be reflected in the SSP and POA&M.
7. Related Policies and Regulations
- Controlled Research Security Policy (CRSP) — https://security.utexas.edu/controlled-research
- Information Resources Use and Security Policy (IRUSP) — https://security.utexas.edu/policies/irusp
- Minimum Security Standards — https://security.utexas.edu/content/min-security-standards
- UT Austin Data Classification Standard — https://security.utexas.edu/policies/data_classification
- Data Encryption Guidelines — https://security.utexas.edu/policies/encryption
- Security Exception Process — https://forms.security.utexas.edu/misc/exception
- International Travel Standard — https://security.utexas.edu/education-outreach/international-travel-standard
- TACC Security and Compliance — https://tacc.utexas.edu/about/security-and-compliance
- NIST SP 800-171 Rev. 2 — https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final
- DFARS 252.204-7012 — https://www.acquisition.gov/dfars/252.204-7012-safeguarding-covered-defense-information-and-cyber-incident-reporting
- CMMC Program (32 CFR Part 170) — https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-D/part-170
8. Revision History
| Version | Date | Notes |
|---|---|---|
| 0.1 | 10/14/2026 | Published; requirements derived from the CRSP standards (security.utexas.edu/policies/controlled-research), and NIST SP 800-171 Rev. 2. |
9. Approvals
| Name | Role | Date |
|---|---|---|
| Chief Information Security Officer | Approval | 10/14/2026 |