DECISION: Data Approval Process for Redshift Data

EDGC Decision Date: May 2, 2024

Decision: Data Approval Process for Redshift Data

Decision

UW System is building data views in Redshift in support of administrative transformation to replace current HR and Finance data warehouses, modernize the CDR data capabilities, and other general analytics capabilities. To effectively manage access to these data assets, UW System needs to develop an approval process that maintains campus control over data but can also be responsive to needs for cross-institutional and enterprise-wide data access.

Background

In current state, much of our enterprise data is only available in an “all or nothing” level of access to a view. In the future, data domains, data classification and row level security will allow more granular access to datasets available within a schema, allowing for more granular data access decisions. As established in the API approval process recommendation that was approved by the EDGC, requests for data at a University will be routed to the University data governance contact to follow the University process for approval, requests for data that span Universities, or that represent an enterprise-wide dataset, should be routed to UW System for review. UWS will work with the EDGC to establish a register of pre-approved use cases for enterprise-wide datasets, and UWS will review requests against that register. If a request cannot be satisfied by a pre-approved use case, the EDGC will determine if it represents a new use case, should be amended, or should be approved as an isolated case. One example of a recently approved use case is that people with access to data in Workday will automatically be granted access to the same data in Tableau for analytic and reporting purposes.

The Redshift data access does not follow the same pattern as the Tableau dataset access. Redshift data can be used for integration to existing data warehouses and data stores and it can be used by individuals who query, combine, transform and add data to create new datasets. Because the uses vary and the individuals may or may not have access to the data in Workday, an ad hoc access process is needed request and review the requests to grant access to Redshift data. Conversely, because many people who use Workday will not use the Redshift data, there is no requirement to automatically grant Redshift data access based on Workday roles.

In support of this process, the Enterprise Data Governance Council (EDGC) will maintain a documented list of university data governance contacts and develop documents to support decision-making processes related to this recommendation.

Recommendation

Develop a request and approval process in Ivanti like the process designed for Integration Hub API access to data. There are 2 types of access requests that are known right now: 1. individual access requests to allow queries and use of the datasets available in Redshift, 2. service account access to extract data that could be used by datawarehouses/datastores or joined to other data warehouse data. Additional use cases may be developed in the future.

In both cases above, the request is initiated by the requester with relevant information about the use of the data. Information needed in the request will include the use of the data, data domain (HR, FIN, Canvas, CDR, etc) and if high risk dataviews are requested. High risk data is defined in the updated data classification policy that will be used for all Universities effective December 1, 2024 (https://www.wisconsin.edu/uw-policies/uw-system-administrative-policies/information-security-data-classification/). The request is routed to the University data steward contact for review using the University’s data governance processes. Once the University’s process approves or rejects the request, the University data governance contact updates the request in Ivanti and access will be granted for approved requests.

Any request for service account access will be reviewed every 6 months to ensure access is appropriate, secure and follows data privacy rules. Individual access will be terminated when employment is terminated and reviewed every 6 months with an attestation process to confirm the individual is still in a position that requires the access granted.

Who Developed the Recommendation?

This recommendation was developed by:

• Stacy Scholtka, Enterprise Analytics Platform
• Dale Johnson, Enterprise Analytics Platform
• HelioCampus, Enterprise Analytics Platform Redshift vendor

Who Was Consulted in the Development of the Recommendation?

The following stakeholders were consulted about the proposed POC:

• Members of the Student Lifecycle product deployments
• ATP project team members
• Tom Jordan, Enterprise Architect Madison
• Diann Sypula, Data Steward for current enterprise warehouses
• Stacey Rolston, Data Privacy Officer UW-Shared Services

DECISION: OktaHub access to HRS/SFS/Workday, SIS and PersonHub Data

EDGC Decision Date: April 22, 2024

Decision: OktaHub access to HRS/SFS/Workday, SIS and PersonHub Data

What is the problem? Why is a decision needed?

Okta is an Identity and Access management tool implemented at the Universities of Wisconsin. The tool combines Okta Spokes deployed at the University level in Phase 1 as an opt-in implementation with Okta Hub deployed at the enterprise level in Phase 2. Okta Hub requires information on all users (faculty, staff, students, POI, etc) who have or will have an active NetID associated with the person. The sources for the identity data needed for OktaHub come from the HR system for employees (HRS/Workday) and the University SIS for Students. OktaHub requires an efficient and effective way to integrate all identity related data across the Universities.

What decision is recommended?

HRS/SFS, Workday, and SIS through PersonHub data feeds are recommended as the source for the identity data needed for OktaHub. The PersonHub data feeds combine HR system person data for employees (HRS/Workday) and the University SIS person data to provide two perspectives on the Person information. The first is PersonHub creates a common identifier across all Universities for a Person called PVI. The PVI provides a way to match a single person with their different identities across Universities (e.g. one person may be faculty at Whitewater, student at Stevens Point and employee at Platteville). The second perspective is information on the person as the University sees the person with their associated login, email and other personal information. Since each identity needs both the combined enterprise PVI and individual University identity to gain access to applications, the PersonHub data feed along with the data coming into PersonHub that retains the campuses identity is the best choice for the data in OktaHub.

A more detailed diagram is available in Appendix 1.

Who developed the recommendation?

This recommendation was developed by the UW System’s OktaHub team and Enterprise Architecture team.

Who was consulted in the development of the recommendation?

Members of UW-Madison’s PersonHub teams and UW System’s Enterprise Analytics program reviewed and contributed to the recommendation document. Additionally, ATP functional and security teams were consulted on issues related to the use of OktaHub and security models for EAP.

Appendix 1 – Technical Diagram

Data will be pushed to the OKTA hub utilizing Otka’s “Anything-as-a-Source (XaaS) api end points.  As data changes it needs to be pushed to Okta in a near real time fashion.  Okta will be in production prior to ATP go live and needs to support both Workday and HRS data.  All user populations including Students are included in the OKTA feed. Okta will use campus provided EPPN (EduPersonPrincipleName) as it anchor and primary identifier.  Okta co-exists with existing federated IAM processes.  OKTA will rely on Person Hub Master Data Management (MDM) services to maintain linkage between EPPN and PVI. The main principle for sourcing data for the hub is that we pull it as close as possible from the source systems. Because of the varied populations these data sources have an order of precedence.  Employee data will be sourced from HRS, and then Workday post go-live.  All other data will be sourced from the campus SIS that is providing it.

Appendix 2 – Proposed List of Initial Use Cases OktaHub

Appendix 3 –Proposed List of Data Elements Required in OktaHub

Canvas Data & Dashboard Provisioning

EDGC Decision Date: March 11, 2024

Decision: Canvas Data & Dashboard Provisioning

Decision

The request is for the EDGC to approve access to Canvas Data and Dashboards on Tableau.  Heliocampus will provision Tableau access to Canvas Data and Dashboards according to a user’s account level role in Canvas as noted in the account users table. Canvas supports FERPA compliance by providing the ability for each Universities of Wisconsin subaccount to define permission settings to specify what data each user can view in that subaccount. Each UW assigns roles in their Canvas subaccount to adhere to FERPA compliance; by aligning Canvas access permissions to Canvas Data and Dashboards in Tableau we ensure the access process remains FERPA compliant.

Background

The Universities of Wisconsin (UW) Digital Learning Environment (DLE) Canvas account is divided into three instances, each containing a variety of sub-accounts. The Canvas Data and Dashboards on Tableau focuses on the Instructional instance of Canvas and all of it’s sub-accounts. The Instructional Instance is used for all instructional credit courses and contains the sub-accounts which are integrated with campus Student Information Systems (SIS) to automatically pull course creation and enrollment data. The Instructional instance of Canvas typically has one “Instructional-Top Level” subaccount for each of the Universities of Wisconsin (excluding UW-Madison), and that university’s subaccount is further subdivided into sub-accounts, each with its own permissions.

There are two types of roles in Canvas: course level roles and account level roles.  Course level roles focus on the access a user needs for a course. Account level roles grant permission to perform tasks within the sub-account where they are applied, and within any sub-account or course below the sub-account where the role is applied. Every role which exists in Canvas is available across all Canvas subaccounts; universities can’t request institution-specific roles which would only be available to users from their university.

For further information on Canvas Instances, Sub-Accounts, or Roles visit the DLE KnowledgeBase (KB).

Account Role Assignment

Access to Tableau Canvas Data and Dashboards will be based on a user’s Account Level Role in Canvas. Account level roles in Canvas grant permissions to perform tasks within the campus sub-account where they are applied, and within any sub-account or course below the sub-account where the role is applied. Each university assigns account level roles in accordance with work needs.

Account Role Support

For user questions on account roles or to request an additional role(s) to access Canvas Data and Dashboards, users will need to consult their campus contact which can be located on this KB page: LINK FORTHCOMING.

Data Access and Account Role Exceptions

Data access requests different from what a user may have as a canvas account role will be reviewed by the campus Canvas account role support for user’s campus data only.  Cross-campus data access requests will be reviewed by UWSA Canvas data steward. Canvas data steward will consult with the Canvas data trustee, DLE institutional liaisons and DLE Advisory Council as part of their review of the use case. Canvas data steward will bring requests that are challenging to resolve to the EDGC.

Who Developed the Recommendation?

This recommendation was developed by:

• Julie Pohlman, DLE Service Owner, Office of Learning & Information Technology Services

Who Was Consulted in the Development of the Recommendation?

The following stakeholders were consulted about the proposal:

• Dale Johnson, Office of Learning & Information Technology Services
• Jason Zapf, Office of Learning & Information Technology Services
• Stacy Scholtka, CTO, Office of Learning & Information Technology Services
• UWs Canvas Database Administrators
• DLE Advisory Council (DLE-AC)
• UWs Institutional Liaisons (DLE-ILs)

Appendix 1: Canvas Account Roles

Workday Data Access Strategy

EDGC Decision Date: March 11, 2024

Decision: Workday Data Access Strategy

Decision

The request is for the EDGC to approve the proposed Workday Data Access Strategy. That strategy can be summarized as the creation of 4 specific analyst roles (view) that are given access to view data within Workday. However, data elements that are deemed sensitive per UW policies, will be restricted regardless of the analyst role a user is assigned.

Background

Workday’s security model provides organizations with a lot of flexibility to customize what users can see in the system. However, other large Universities who have implemented Workday have cautioned that such flexibility often leads to overly, and unnecessarily, complex security models. With that, ATP has developed a recommendation that balances both the need to protect sensitive data and the need to keep the security model simple and manageable.

Problem Statement:

• Need to protect sensitive data when necessary.
• Data access within Workday is complex – it’s an intersection of the security roles assigned to the position, how a report is shared, and how the data is secured.
• Most UW users will need to see more information than they will need to act
• Need to ensure that users have access to the data (see) they need to do their jobs on day one
• Want to create a seamless user experience by delivering curated reports to workers based on system access.

The Recommended Solution:

1. Protect elements that are required to be protected – Know what data we need to protect and limit access to it.
2. Allow view to everything else – Create a limited amount of “view” roles that allow access within a domain and across domains when needed.

How ATP Plans to Implement:

ATP plans to start with the creation of 4 analyst roles (“analyst” roles allow users to view things in Workday). This list will likely grow as this concept is built out. There will be data that is not aligned with HR or Finance (audit logs, security roles, etc.) that will need to be accommodated. The 4 starting roles are:

1. HR data for HR professionals
2. HR data for non-HR professionals
3. Finance data for Finance professionals
4. Finance data for non-finance professionals

For each analyst role, ATP will review to ensure that data elements that fall within a protected classification are restricted from access, regardless of which of the 4 analyst roles a user may have. Such analysis will be conducted with current UW data classification and data protection policies as guides. After the analyst roles are created, with data restricted, ATP will test to ensure that access to data is as expected before assignment to end users.

Benefits of this approach (based on our principles)

• Enables Access to Data – This is one of the primary principles ATP was founded on. Our current data landscape at the UW is one in which many end users have access to a lot of data (WISER, OBIEE, etc.). This approach allows us to carry this forward.
• Just Enough Complexity – A common pitfall of Workday implementation is a complex security model that is unmanageable post-go-live. This approach keeps the analyst (view) roles simple to manage.
• Four mores – More data, to more people, more easily, for more purposes.
• Workday First – With this broader view access, we can keep users within Workday to view data and access reports when it makes sense.
• Future proofing our technology – Do not back ourselves into customization corners or one-off solutions.

Implications for EAP

The EAP security model (access to data via Tableau) will be based on the Workday approach. This will allow for consistency to ensure users have access to similar data in both places. Once the roles are built within Workday, assignments can be fed to EAP to replicate. Personal Identifiable Information (ex. SSN) data will be secured within EAP with a tokenization strategy.

Who Developed the Recommendation?

• Kurt McMillen – ATP Data & Reporting Strategy Lead
• Susie Maloney – ATP Finance Strategy Lead
• Allion Niles – ATP Human Resources Strategy Lead
• Nysa Stryker – ATP Cross-Functional Strategy Lead
• Stacy Scholtka – UWSA, Chief Technology Officer
• Brad Roll – Workday Data & Reporting Strategy Lead

Who Was Consulted in the Development of the Recommendation?

• ATP Finance Governance
  • https://atp.wisconsin.edu/governance/
• ATP Leadership
  • https://atp.wisconsin.edu/program-team/ (Listed under “program leadership”)
  • In addition, these other key individuals have had the opportunity to review:
    • Adam Paulick
    • Rolston, Stacey
    • Huron counterparts
  • UW-Madison Badger Analytics Council
    • https://data.wisc.edu/data-governance/data-governance-council/

ATP (Workday) Integrations Governance Process and Approval Proposal

EDGC Decision Date: February 12, 2024

Decision: Workday Integrations

Decision

In close collaboration with ATP functional teams (Finance, HR, Research Administration), the ATP Integrations team is designing, building, and testing direct inbound and outbound integrations between Workday and key partner agencies, vendors, and ancillary systems. The request is for the EDGC to approve the proposed interim approach for determining what data may be included in Workday integrations while Workday is being implemented. This proposed approach is intended to allow ATP to continue with the timely development of required integrations for Workday go-live.

Background

In order to support a successful transition from PeopleSoft HCM (HRS) and FSCM (SFS) to Workday, a number of integrations to external partner agencies, vendors, and ancillary systems are necessary. The number of ancillary systems with which we directly integrate to/from Workday is intentionally being limited in order to ensure that we do not negatively affect tenant performance (Reference: Integrations and Web Service Limits on Workday Community). The ATP Integrations team has a current backlog of 160 integrations that have been determined necessary for a successful go-live. The requirements for these integrations, along with their prioritization, are driven by the ATP functional teams. In this relationship, ATP Integrations is a consultant, partner, and implementer.

The integrations currently being developed include connections between Workday and the following entities/systems:

Of the 160 integrations that are in-scope for go-live, 76 are for Finance, 69 are for HCM, and 15 are for Research Administration. As of Friday, February 9^th, 98 of these integrations have been completed and moved to the end-to-end testing tenant (Wisconsin 8).

Interim Approach

Workday integration development has been proceeding for the past year, with requirements driven by the ATP functional teams. Integration development follows these steps:

1. Current State Design Documentation – ATP Integrations in collaboration with SMEs
2. Future State Design Documentation – ATP Integrations in collaboration with ATP Functional Team
3. Design Review (Internal) – System Implementation Partner (Huron)
4. Future State Design Signoff – ATP Functional Team
5. Coding – ATP Integrations
6. Unit Testing – ATP Integrations, sometimes in collaboration with ATP Functional Team
7. Build Review (Internal) – System Implementation Partner (Huron)
8. E2E Readiness – Functional Signoff – ATP Functional Team

The proposed interim approach is to continue with the current state where the ATP Functional Teams are responsible for determining the data necessary and appropriate to be included in the Workday integrations.

Person Hub

To support the transition from PeopleSoft to Workday for the current master identity management solution (Person Hub) that is leveraged by all campuses within the Universities of Wisconsin, a dedicated Person Hub Tiger Team was established in June 2023 consisting of representation from the Person Hub development team (UW–Madison DoIT AIS IAM), the ATP Cross-Functional team, and the ATP Integrations team. Together, and in consultation with ATP HR and ATP Finance when relevant, this Tiger Team has worked closely to identify requirements, create a design, and implement a solution. The steps outlined in the Interim Approach section above have also been followed for this body of work. Issue escalation and resolution has been handled through a leadership team consisting of:

• Steven Hopper, Associate Vice President for Learning and Information Technology Services and Chief Information Officer, Universities of Wisconsin
• Lois Brooks, Vice Provost for Information Technology and Chief Information Officer, UW–Madison
• Kevin Donahoe, ATP Program Director
• Allison Niles, ATP HR Strategy Lead
• Susie Maloney, ATP Finance Strategy Lead
• Adam Paulick, Executive Director, UW–Madison DoIT Enterprise Business Systems
• Joe Tarter, Director, UW–Madison DoIT Application Infrastructure Services

ShopUW+ (Jaggaer)

To support the transition from PeopleSoft to Workday for the current eProcurement platform (Jaggaer, a.k.a. ShopUW+) that is leveraged by all campuses within the Universities of Wisconsin, and to align with the Workday-first model that was agreed upon as the path forward in October 2023, a Supply Chain Management working group was established in November 2023. This group includes representation from ATP Finance’s Supply Chain Management team, Accounts Payable, Procurement, ShopUW+ Administration, ATP Integrations, and Huron (in the Jaggaer, Workday SCM, and Integrations spaces). Together, this working group has worked closely to identify requirements, create a design, and is currently working through configuration and solution implementation. The steps outlined in the Interim Approach section are being followed for this body of work, with the exception that additional functional team unit testing is happening as integrations are developed in the Integration Development tenant (Wisconsin 11), before migrating those integrations to the End-to-End Testing tenant (Wisconsin 8). This is the result of us only being able to connect the Jaggaer development instance to a single Workday tenant at any one time, and is only expected to be a consideration during implementation. Issue escalation and resolution has been handled through the standard path for ATP:

1. ATP Leadership Team
2. ATP Finance Governance (if needed)
3. Executive Sponsors (if needed)

Student Information Systems (SIS) for Campuses

To support the transition from PeopleSoft to Workday for the current Student Information Systems (PeopleSoft Campus Solutions), a number of SIS work groups and a broad SIS Connections group were formed in the spring of 2023. The work groups include:

• Employee Data to SIS
• Student Data to Workday
• UDDS Replacement for Academic
• General Ledger
• Student Refunds

A dedicated ATP SIS Architect joined the Administrative Transformation Program in May 2023 and has been leading the coordination of work in this space. All campuses have had the opportunity to identify key staff for participation in the SIS work groups and the SIS Connections group meets on a bi-weekly basis to provide updates to a larger audience and solicit feedback and input from campus teams. The SIS Architect works closely with the SIS work groups, UW Shared Services, ATP functional teams and ATP Integrations to identify requirements, create a design, and implement a solution. The steps outlined in the Interim Approach section above have also been followed for this body of work. Issue escalation and resolution has been handled through the following path:

1. SIS work groups, Registrar’s Offices, and others as needed
2. ATP Leadership Team
3. ATP Functional Governance (if needed)
4. Executive Sponsors (if needed)

Who Developed the Recommendation?

This recommendation was developed by:

• Morgan Andersen, ATP Integrations Strategy Lead

Who Was Consulted in the Development of the Recommendation?

The following stakeholders were consulted about the proposal:

• Susie Maloney, ATP Finance Strategy Lead
• Kurt McMillen, ATP Research Administration Strategy Lead
• Allison Niles, ATP HR Strategy Lead
• Sowmya Shankar, ATP Integration Dev Team Lead
• Amanda Smith, ATP SIS Architect

[1] This includes the UW–Madison Cross-DEM/SIS Workgroup

Data Approval Process for Enterprise APIs

EDGC Decision Date: July 31, 2023

Decision: Data Approval Process for Enterprise APIs

Decision

UW System is building out data integration and analytics capabilities in support of administrative transformation, most notably in the form of institutional APIs and data assets which are themselves supported by an enterprise data lake. To effectively manage access to these data assets, UW System needs to develop an approval process that maintains campus control over data but can also be responsive to needs for cross-institutional data access.

Background

Requests for data that span institutions, or that represent a System-wide dataset, should be routed to UW System Administration (UWSA) for review. UWSA will work with the EDGC to establish a register of pre-approved use cases for systemwide datasets, and UWSA will review requests against that register. If a request cannot be satisfied by a pre-approved use case, the EDGC will determine if it represents a new use case, should be amended, or should be approved as an isolated case.

In support of this process, the Enterprise Data Governance Council (EDGC) will document existing institutional data governance processes and develop supporting documents to support those decision-making processes.

A more detailed procedure is defined in Appendix 1.

Who Developed the Recommendation?

This recommendation was developed jointly by:

• Tom Jordan, UW-Madison’s Ancillary Systems Program
• Stacy Scholtka, UW System’s Enterprise Analytics Program

Who Was Consulted in the Development of the Recommendation?

The following stakeholders were consulted about the proposed POC:

• Members of UW-Madison’s API development teams and UW System’s Enterprise Analytics program reviewed and contributed to the principles identified in Appendix 1
• Additionally, ATP functional and integration teams consulted on issues related to data access and approval for integrations.

Appendix 1: Recommended Procedure for Data Approval for APIs and Data Lake Assets

Principles

• Campuses retain the ability to make decisions about their own data, through their data stewards, even when that data resides in enterprise-wide information systems.
• Access to data assets should be based on a legitimate university interest, and should involve consideration of risk, impact, and business need.
• The EDGC will determine appropriate uses of enterprise-wide data sets or integration services, including institutional APIs that provide access to data for all campuses.
• UWSA will manage the request and approval process, including evaluating requests against a set of pre-approved use cases. UWSA will not judge the merit of a request beyond its technical feasibility.
• EDGC will consider new use cases for system-wide datasets and services as the need arises.

ATP Conversion POC – Data ingestion from Oracle HRS/SFS to AWS S3

EDGC Decision Date: July 16, 2023

Decision: ATP Conversion POC – Data ingestion from Oracle HRS/SFS to AWS S3

Decision

This ATP conversion request is for actual data from our current HRS and SFS system (including PII data like full SSN, bank accounts, etc.) to be moved from the source system to Amazon S3, then to Workday for the conversion. The data will be converted into Workday and will follow the security policies of the ATP Workday team. Once the data is in Workday, the data will be secured using role-based security that is being designed by the ATP Functional teams. The data loaded to stage tables in AWS S3 is not going to persist past the go-live, all security is then passed to the Workday teams.

Background

The success of ATP Conversion depends, in part, on quickly and safely ingesting data from Oracle Exadata sources (including HRS and SFS), transforming that data to meet business requirements for Workday and ultimately loading the data to Workday via excel files.

The ATP Conversion Team has identified roughly 220 source tables needed to create the Workday files and present to our implementation partner to load to Workday. Some of these data sources contain highly restricted data such as social security numbers and bank accounts. This data will ultimately reside in the Workday cloud environment.

The team has been using a combination of Exadata, SQL, IICS and Python to build out the tenants for the project to date. The team requested permission to use AWS and AWS tools to ingest the data from SFS and HRS to an S3 raw layer.

The Conversion Team will utilize the following serverless services within AWS – S3, Glue, Athena, KMS (for encryption), IAM (for permissions) and Cloudwatch Logs (for logging). For ingestion, the team will use on-prem servers running hadoop/spark which won’t need any firewalls to be opened.

The goal for this POC is to evaluate the efficiency of using AWS. As we approach the go-live date, it is critical to continue to shrink the timelines for pulling and transforming the data to limit disruption to daily operations.

The team has anticipated this transition for 6 months and have been developing current code in a manner that will require little rework to test the POC. The team has been working with the DoIT Cloud Team to stand up the environment for ingestion. The team has met with Cyber Security, completed the assessment, and taking all necessary mitigation measures as it relates to this data.

This POC request is extremely limited to a small team of ATP Conversion developers and a key subset of HRS & SFS data. The team has tested the process of pulling public data to an S3 bucket in the AWS environment and the final step is to connect to Exadata to pull true data. The team has an expert AWS Engineer on the team who has been working to set up the environment and will manage the ingestion POC.

Who Developed the Recommendation?

• Michelle Weber, ATP Conversion Strategy Lead
• Brian Zehren, Associate Director, ERP App Support
• Shiva Prakash, Conversion Cloud Engineer
• Mike Vavrus, DoIT Cloud Engineer

Who Was Consulted in the Development of the Recommendation?

The following stakeholders were consulted about the proposed POC:

• Pam Snyder, Cloud Security Risk Analyst
• Steve Tanner, Cloud & Security Eng Associate Director
• Steffanie Johnson, Info Security Analyst IV
• Kristy Rogers, ATP IT Security Lead and HRS Security Lead
• Al Kantor, Cloud Data Architect

Data classification of enterprise data according to risk

EDGC Decision Date: April 24, 2023

Background

The success of ATP/EAP/ASP projects depends, in part, on classifying enterprise data elements across enterprise systems in a standard way.

UW System Administrative Policy 1031 calls for data to be categorized as high, moderate, or low risk. It provides standards for classification and minimum protections for each level of risk. Data classification “determines the extent to which technical, administrative, and physical controls should be applied to protect the data from theft, alteration, loss of integrity, and/or misuse.” SYS 1031 is currently under revision.

UW-Madison employs a classification system with four categories: public, internal, sensitive, and restricted (per UW Madison IT policy UW-504) spanning the spectrum of low to high risk. Many developers working with enterprise data across the ATP/EAP/ASP portfolio are from UW-Madison and are accustomed to UW-Madison’s classification system. Data in UW-Madison’s ancillary systems use UW-Madison’s classification system.

Lack of agreement on a single risk classification may result in developers applying different classifications in Workday vs. the data lake vs. ancillary systems. This reduces the opportunity to apply a common set of security roles across enterprise systems, and where possible, ancillary systems. And it could lead to inconsistent access and security of enterprise data.

Decision

APT/EAP/ASP apply the draft data classification schema (below) that brings together existing Madison and UW System policy in anticipation of the pending revision, noting that this MAY change by the time the policy revision is fully vetted.

Draft Data Classification Schema

Who Developed the Recommendation?

• Joe Johnson, UWSA Director of Governance, Risk, and Compliance
• Lisa Johnston, UW-Madison Director of Data Governance

Who Was Consulted in the Development of the Recommendation?

The following stakeholders were consulted about the proposed data classifications, in the context of the forthcoming revision of SYS 1031. These stakeholders have supported the general direction being proposed and have not raised any initial concerns. However, the proposed data classification may change during the SYS 1031 revision over the coming months.

• Ed Murphy (UW System, AVP Information Security)
• Jim Treu (UW System, Director of Security Awareness and Outreach)
• Mike Bubolz (UW Breen Bay, Interim CIO)
• Patti Havlicek (UW-Madison, RMC Asst. Director)
• Other various Technology and Information Security Council (TISC) representatives
• UW Madison Data Stewards
• UW Madison IT Policy Advisory Team (subcommittee of Information Technology Council)