Quick Overview
- This is one of the information security policies that together make up SFA 06-107 and satisfy the state and UT System rules SFA must follow.
- It sets the university's high-level goals for the technology safeguards that protect our systems, devices, data, and IT facilities, covering everything from account access to incident response.
- It applies to everyone who uses SFA information resources, including employees, students, contractors, vendors, and research partners.
- A policy says what we must achieve. The matching standards say how. This policy points to six supporting standards (06-107.2.1 through 06-107.2.6).
- Following SFA 06-107 is mandatory. Not following it can lead to disciplinary action.
Stephen F. Austin State University relies on technology to carry out its mission, and that technology has to be protected.
This policy establishes the university's expectations for the technical safeguards that keep SFA systems, devices,
data, and IT facilities secure. It covers how we control who can access what, how we manage and maintain
our systems and assets, how we keep services running during a disruption, and how we watch for and respond to
security threats and incidents. It does not contain step-by-step technical instructions; those live in the supporting standards and procedures.
Think of this policy as the "why and what" that the technical standards build on.
|
i
|
How the pieces fit together
Policy = the goal (what SFA must achieve).
Standard = the requirement (the specific rules that meet the goal).
Procedure = the how-to (the exact steps a team follows).
This document is a policy, and it is supported by six standards listed near the bottom of this article.
|
Who This Applies To
This policy applies to all users of SFA information resources, including:
- SFA employees (faculty and staff) and student workers
- Contractors, vendors, and other third-party service providers
- Research partners and other authorized users of SFA systems, assets, and data
- Visitors and contingent workers who use SFA technology or work inside IT facilities
Wherever you see an italicized term in the full policy, its exact meaning is in the SFA 06-107 Definitions.
Who Is Responsible
The policy assigns specific duties to leaders at both the UT System and SFA levels. Most users won't hold these roles,
but it helps to know who is accountable. Expand for a plain-language summary of the key roles.
Key roles & responsibilities
⌄
A note on names: At SFA, the senior information security role is the Chief Information Security Officer (CISO). There is no separate "Information Security Officer" position. The abbreviation ISO at SFA refers to the Office of Information Security (the office that supports the CISO), not to a person. This article uses CISO for the person and Office of Information Security for the office.
At SFA (Institution level)
- Agency Head (President): Ensures SFA complies with 06-107, appoints the CISO, funds the security program, and ensures corrective action is taken for non-compliance.
- Chief Information Security Officer (CISO): Runs SFA's information security program and has independent oversight of security across centralized and decentralized IT.
- Information Resource Manager (IRM): Implements the security controls and system-management practices across the university.
- Privacy Officer (PO): Guides how the university safeguards records and personal information, including protected health information where HIPAA applies.
- Research Security Officer (RSO): Runs the research security program.
- Data Management Officer (DMO): Oversees how data is classified, managed, and protected across its lifecycle.
- Chief Business Officer (CBO): Ensures procurement includes security and privacy review of vendors.
- Resource owners, custodians & security administrators: Grant, control, and monitor access to systems and data, and implement the required protections.
- IT Lead of High Risk Assets: Ensures the architecture, backup, and recovery strategy for high-risk assets are adequate and properly protected.
- All users: Must follow every 06-107 policy and standard when using SFA information resources.
At the UT System level
Systemwide leaders, including the Chancellor, the UT System CISO, CIO, Chief Privacy Officer, Chief Risk Officer, Data Management Officer, and the Risk Management Executive Committee (RMEC), set direction, issue the policies and standards, and designate certain assets as "high risk."
Full role definitions
The complete list of responsibilities for every role is in the attached policy PDF (Sec. 3, Authority).
What This Policy Covers
The policy is organized into six goal areas. Each area sets objectives that are carried out through a supporting technology standard.
Expand any section below to see what it covers in plain language and which standard puts it into practice.
4.1 Access Management
Who can get in, and how
⌄
SFA must make sure only the right people and devices can reach its systems and data, with each user given the least access they need to do their job.
- Identity management: Manage accounts through their whole lifecycle, from creation and changes to removal, and define which account types are allowed and what each can do.
- Segregation of duties: Split up conflicting tasks so no single person has enough access to misuse it.
- Access control: Grant, review, change, and remove access so people get only the least access they need, covering regular, privileged, shared, and service accounts.
- Remote access security: Protect connections made from off campus or outside networks, including what remote access is allowed and how it must be configured.
- Secure authentication & logon: Confirm the identity of every user and device before access is granted, and manage passwords and other authenticators securely.
Put into practice by
SFA 06-107.2.1 Access Management Standard
4.2 Asset Management
Knowing and protecting our equipment & data
⌄
SFA must keep track of its technology assets and information resources and protect them properly from purchase all the way through disposal.
- Asset management: Manage assets across their whole lifecycle (development, purchase, use, transport, and disposal) using a defined classification and handling scheme.
- Inventory & maintenance: Identify, classify, and inventory assets so ownership is clear and the ones critical to the mission are tracked, including their recovery targets.
- Acceptable use of assets: Set and communicate rules for using assets, software licenses, and off-site equipment appropriately.
- Return, disposal & reuse: Collect equipment when someone leaves or changes roles, and securely wipe, dispose of, or reuse it (and document anything lost or stolen).
Put into practice by
SFA 06-107.2.2 Asset Management Standard
4.3 System Development & Maintenance
Building & maintaining systems securely
⌄
When SFA builds, buys, configures, or changes systems, security has to be built in from the start and maintained over time.
- Secure architecture & engineering: Follow documented secure-design principles for all development, with clear ownership of each system.
- Separate environments: Keep development, testing, and live (production) environments apart, and avoid using real production data for testing.
- Configuration management: Set approved baseline configurations and watch for unauthorized or incorrect changes.
- System hardening & least functionality: Turn off features and services that are not needed so systems have a smaller attack surface.
- Change management & maintenance: Document, analyze, approve, and test changes (including emergency changes) so security is preserved.
- Installation of software: Control how software is installed to avoid introducing vulnerabilities, and honor license and terms-of-service requirements.
- Secure coding: Apply secure coding requirements when developing or acquiring systems.
Put into practice by
SFA 06-107.2.3 System Development & Maintenance Standard
4.4 Business Continuity & Disaster Recovery
Keeping services running & recovering fast
⌄
SFA must plan ahead so that critical services keep running during a disruption and can be recovered quickly afterward.
- Impact analysis: Identify critical assets and the systems they depend on, and analyze the business impact of losing them.
- Business continuity plans & testing: Build, maintain, and periodically test plans that keep critical functions (and their security) going during disruptions, including support from vendors.
- Disaster recovery plans & testing: Build, maintain, and test plans to restore systems to a known state within agreed timeframes after an outage or incident.
- Backup methods: Generate, store, protect, and test backups of critical data and software so they can be recovered after loss or corruption.
- Capacity management: Plan and monitor processing, telecommunications, and environmental capacity so critical systems can fail over and keep operating.
Put into practice by
SFA 06-107.2.4 Business Continuity & Disaster Recovery Standard
4.5 Security Monitoring & Vulnerability Management
Watching for threats & fixing weaknesses
⌄
SFA must actively watch for security threats, find and fix weaknesses, and protect its networks, systems, and cloud services.
- Threat intelligence & management: Collect and analyze information about current threats and monitor for them so SFA can respond in time.
- Vulnerability identification & remediation: Scan for weaknesses, rank them by risk, and fix them before they can be exploited.
- Penetration testing: Periodically test defenses (safely simulating an attack) to find gaps and confirm controls work.
- Protection against malware: Use up-to-date methods to detect and block malicious or flawed code.
- Network security: Protect networks and devices with boundary protection, traffic restrictions, secure communications, and defenses that limit an attacker's movement.
- Management of cloud services: Secure cloud services from acquisition through exit so SFA data in the cloud stays protected.
- Logging: Record the right events with enough detail to spot and investigate security incidents.
Put into practice by
SFA 06-107.2.5 Security Monitoring & Vulnerability Management Standard
4.6 Incident Management
Reporting & responding to security incidents
⌄
When something goes wrong, SFA must be ready to report it, respond to it, contain it, and learn from it.
- Security incident reporting: Provide clear ways to document, track, and report suspected incidents to the right people through the right channels.
- Vendor incident reporting: Require vendors that handle SFA data to report suspected incidents promptly.
- Incident response planning: Build, test, and communicate response plans that define roles, steps, and reporting channels.
- Responding to incidents: Follow defined handling procedures based on the type of incident to resolve it efficiently.
- Learning from incidents: Capture evidence and lessons learned and use them to strengthen future defenses.
- Incident communication: Define what must be reported (and when) to law enforcement, regulators, vendors, the public, and others.
|
!
|
Important
The Office of Information Security (through the CISO) must have unrestricted access to all logs and incident-related data and cannot depend on any other IT group to obtain it. If you suspect a security incident, report it right away; do not wait.
|
Put into practice by
SFA 06-107.2.6 Incident Management Standard
Compliance, Exceptions & Enforcement
Compliance with SFA 06-107 is mandatory unless a written contract says otherwise or a formal exception has been granted.
If a requirement genuinely can't be met and there's no workable fix, a user may request an exception through the SFA
Chief Information Security Officer (CISO), who weighs the business need against the risk and may approve it with compensating protections. All approved exceptions are logged at the institution level.
|
!
|
Important
Violations of SFA 06-107 may lead to disciplinary action, up to and including involuntary separation from employment.
Exceptions are never granted to the Acceptable Use Standard (06-107.1.6).
|
Compliance Mapping (Reference)
This section is for auditors, security staff, and anyone who needs the underlying control references. Everyday users can skip it.
Frameworks & control references
⌄
SFA 06-107.2 was written to align with the following authoritative sources cited in the policy:
- Texas Administrative Code (TAC) 202, Subchapter C: the state rule for information security at Texas institutions of higher education.
- Texas DIR Security Controls Catalog: the state's baseline control set.
- NIST 800-53 Revision 5.1.1: the federal security and privacy control catalog.
- Additional privacy regulatory obligations where relevant (for example, HIPAA for protected health information at covered or hybrid entities).
Each objective in the policy lists the specific control numbers it maps to (for example, NIST AC-02, TAC 202 202.72,
DIR AC-2). The complete objective-by-objective mapping is in the attached policy PDF and in the
SFA 06-107 Controls Crosswalk.
Related Policies & Standards
This policy is carried out by the following standards:
Related standards:
Responsible office: Office of Information Security, Privacy Officer ·
Contact: itsecurity@sfasu.edu, privacyofficer@utsystem.edu
|
📎
|
Official document
The complete, official policy is attached to this article as a PDF, including its full objectives, role definitions, and control mappings. This article summarizes that policy in plain language. If anything in this article conflicts with the attached PDF, the PDF is the official version and takes precedence.
|
Need Help?
Contact the IT Help Desk at
(936) 468-4357 (HELP) or submit a ticket at
help.sfasu.edu.
For questions about this policy, contact the Office of Information Security at
itsecurity@sfasu.edu.