Shared Services Supplemental Policy Preliminary Recommendations Financial Management

Shared Services Supplemental Policy Preliminary Recommendations Financial Management, Information Sharing, and Shared Services COI April 2016 Advancing Government through Collaboration, Education and Action

Contents • • Finding Summary Privacy Impact Assessment Challenges – • • System Of Record Notification Challenges in a Shared Services Environment PIA and SORN Recommendations: Clarify Data Ownership – – – • • Recommendation #1: Revise SORN & PIA Guidance Recommendation #2: Establish a Baseline Standard RACI Recommendation #3: Create a Standard Shared Services Agreement/Contract Section 508: Inconsistent Implementation Section 508: Recommendations Observations for Promoting Accessible Shared Services Project Information – – – • Privacy Impact Assessment Challenges Project Team Project Timeline & Impacts Shared Services Policy Project Methodology Backup Information – Starting Checklists Advancing Government through Collaboration, Education and Action 2

Finding Summary To reduce conflicts and smooth the path for success, policy owners needs to provide implementation and responsibility guidance for these, and similar policies, to ensure consistent adoption in the U. S. government shared service environment. Important specifics are provided in the following materials. The next 3 slides present the starting Issue Statements from which the Project Team produced the findings and recommendations in this report. Advancing Government through Collaboration, Education and Action 3

Issue #1 Unifying System of Records Notice (SORN) Requirements for FSSPs do not have the same requirements for their customer agencies with regard to publishing SORNs for customer records. • Example: For a shared services implementation, a customer agency took the position that it should not have to issue the SORN for its implementations with a Federal SSP because the SSP was a shared service provider who owns the systems. The Federal Provider disagreed and concluded that its recommendation was inconsistent with OMB guidance. In this environment of shared responsibility, who owns the SORN? Advancing Government through Collaboration, Education and Action 4

System Of Record Notification Challenges in a Shared Services Environment Challenges Findings • As required by The Privacy Act, SORNs identify the legal authority for collecting and storing the records, what kinds of information is collected, and how the records will be used. • System of records consists of any item, collection, or grouping of information about an individual for which records can be retrieved searching by name or other identifier unique to the individual. • Moving into a Shared Services arrangement triggers a SORN publication since this represents record handling and protection changes. • Current policy is not clear about data ownership when records processing belongs to a shared services provider on behalf of the customer agency, resulting in confusion on how to comply with the Privacy Act. • Customer Owns the Data – – – Customer has accountability for audits and accuracy of data reporting to all external stakeholders: congress, citizens, etc. Provider responsible for systems and access to the systems At times provider is responsible for data entry or other processes; however, ultimate accountability for data is with the customer Customer defines the data they collect, uses, and whether PII Customer reviews and accepts the providers PIA security controls given the data they collect Consistent with commercial practices as shared by ACT-IAC member companies Advancing Government through Collaboration, Education and Action 5

Issue #2 Owner of Privacy Impact Assessment (PIA) Between Customer Agency and FSSP Ambiguous There is a key distinction between the system (machines) and the system of record (data). The Privacy Act impact (SORN) for the data is for the data owner (customer) to resolve, but the Privacy Impact Assessment is related to the access controls for the machines which the provider owns. The PIA should be the responsibility of the owner of the machines. However, the PIA is based on the data contained on the machine, but that doesn't transfer legal responsibility for that data to the owner of the machine. In this shared environment, how is PIA responsibility shared? Advancing Government through Collaboration, Education and Action 6

Privacy Impact Assessment Challenges Findings • Per the e. Gov Act of 2002, agencies are required to conduct privacy impact assessments for electronic information systems. • Privacy Impact Assessment (PIA) is an analysis of how information is handled: (i) to • Customer Agency is the Data Owner ensure handling conforms to applicable legal, regulatory, and policy requirements regarding privacy, (ii) to determine the risks and effects of collecting, maintaining and disseminating information in identifiable form in an electronic information system, and (iii) to examine and evaluate protections and processes for handling information to mitigate potential privacy risks. – Customer has accountability for audits and accuracy of data reporting to all external stakeholders: congress, citizens, etc. – Customer defines the data they collect, use, and determine if its PII – Customer reviews and accepts the providers PIA security controls per the data being collected and handled – This is consistent with commercial practices as shared by ACT-IAC member companies • Current policy is not clear about data ownership when records processing is • Moving into a Shared Services arrangement done by a shared services provider on triggers the requirement to publish a new PIA behalf of the customer agency. as this move affects how PII data is • There is confusion on how to comply handled/protected in the Provider’s system(s). with the e. Gov Act. Advancing Government through Collaboration, Education and Action 7

PIA and SORN Recommendations: Clarify Data Ownership Recommendations • o o 1. Updated Guidance • DATA OWNERSHIP 2. Clarify Roles Recommendation #1: Revise and Reissue Official SORN and PIA Guidance: Recommendation #2: Establish and Publish a Baseline Standard RACI for Service Providers and Customers (slide #15 -19) o o o 3. Standard Agreement • Include Data Driven examples for clarification Align with Modernization and Migration Management (M 3) Playbook (formerly FAME 2. 0) guidance Ensure roles and responsibilities are clear Supplement with Data Driven examples Include in M 3 guidance Recommendation #3: Establish a Shared Services Agreement o o o Provide consistent language, cover most situations Consider using standard industry clauses (slide 7) Supplement with Use Cases as Guidance o Use Case = a collection of possible scenarios related to a particular goal often used to ensure all possibilities are covered in policy, requirements, etc. (Per standard practice, issue notice to allow 60 -days to review these new standards, inviting feedback from the shared services community of practice) Advancing Government through Collaboration, Education and Action 8

Recommendation #1: Revise SORN & PIA Guidance Why We are Making this Recommendation: 1. Clarify the SORN Process and Purpose – Observations: • Agencies see SORN as a system driven requirement rather than being a data focused requirement • Agency data owners retain accountability and responsibilities associated with Systems of Record Notification in a shared services arrangement. Needs to be very clearly stated – reinforced messaging is needed • Agency customers retain responsibility for properly securing system interfaces (if up-stream and back-end systems use data being processed by their Provider. Accountability does not transfer to the Provider) 2. Revise OMB Guidance for PIA – Observations: • Customer agency needs to prepare a SORN and PIA for the data for which they retain responsibility – not the Provider’s role • Only the Customer knows about the sensitivity and handling requirements for their agency’s data 3. Provide Representative Examples for Dealing with Common Shared Services Scenarios in M 3 Playbook (Perhaps as a Supplemental Document) – Observations: • e. Discovery - Contractual discovery element is needed to disclose which e. Discovery tools work with Provider’s system (RACI to determine tool ownership and procurement responsibility) • SLAs – Provider establishes agreed upon SLA for FOIA data calls • Agency owner is accountable for FOIA compliance Advancing Government through Collaboration, Education and Action 9

Recommendation #2: Establish a Baseline Standard RACI Standardized RACI Provides a Standardized Basis for Activities and Expectations A RACI matrix describes the participation by various roles in completing tasks or deliverables for a project or business process. It is especially useful in clarifying roles and responsibilities in cross-functional/departmental projects and processes. RACI is an acronym derived from the four key responsibilities most typically used: Responsible, Accountable, Consulted, and Informed. This link goes to a draft shared services RACI -- initial mapping based on what is documented in both FAME 1. 0 and M 3 Playbook processes. This mapping can be leveraged by USSM to create a baseline leading to a standardized Shared Services RACI. Provider High-Level Responsibilities Customer High-Level Responsibilities • • • Provide shared service platform to meet the Customer’s transactional and performance requirements Secure the platform and verify security controls Establish SLAs about responding to Customer needs to access data (including FOIA requests and other legal responses per customer time constraints) • • Profile their data – sensitivity and special handling Establish data lineage – source, custodial, access and control Review and acceptance of Provider’s security controls Expose for negotiation any upstream and back-end interfaces requirements The project team created two RACI views: The link above is for the RACI mapping to FAME 1. 0 and M 3 Playbook (formerly FAME 2. 0). Slides 9 -13 provide our non-vetted RACI related to SORN and PIA responsibilities. Advancing Government through Collaboration, Education and Action 10

SORN Information Sources RACI SORN Section Customer Agency System Identifier X System Name X System Location X Categories of Individuals X Categories of Records X Authority for Maintenance SSP X Support X Purposes X Support Routine Uses X Support Retrieving, Accessing, Retaining, Disposing Storage Policy about Records in System Retrievability X Safeguards X Support Retention and Disposal X Support Systems Manager(s) & Address X Support Notification Procedures X Record Access Procedures X Contesting Records Procedures X Record Source Categories X Exemptions Claimed for the System X Support Customer Agency roles are retained for SORN regardless if the applications operations are outsourced Advancing Government through Collaboration, Education and Action 11

PIA Sources RACI - 1 PIA Section (abbreviated) Customer Agency Abstract X Overview X SSP Section 1. 0 Authorities and Other Requirements 1. 1 Authorities / Agreements X Support 1. 2 Applicable SORNs X Support 1. 3 Security Plan Complete? X Support ATOs and C&A 1. 4 NARA Records Retention Schedule X Support 1. 5 Paperwork Reduction Act OMB Control No. X Support 2. 1 Information Identification X Support 2. 2 Information Sources and Collection Methods X Support 2. 3 Commercial or Public Data Use X Support 2. 4 Data Accuracy Ensured How? X Support 2. 5 PIA Related to Characterization of Information X Support Section 2. 0 Characterization of the Information Support by SSP includes general information about the generic shared services system and potentially collaborative review of the PIA. Supporting narratives for each line item are needed for guidance clarity. Advancing Government through Collaboration, Education and Action 12

PIA Sources RACI - 2 PIA Section (abbreviated) Customer Agency SSP 3. 1 How and why information is used X Support 3. 2 Use of technology for searches and use X Support 3. 3 Agencies with assigned roles/responsibilities X Support 3. 4 PIA Related to the Uses of Information X Support 4. 1 Notice to Individuals before Data Collection X Support 4. 2 Individuals Consent Opportunities X Support 4. 3 PIA Related to Notice X Support 5. 1 How Long and For What Reason X Support 5. 2 PIA Related to Retention X Support Section 3. 0 Uses of Information Section 4. 0 Notice Section 5. 0 Data Retention by Project Advancing Government through Collaboration, Education and Action 13

PIA Sources RACI - 3 PIA Section (abbreviated) Customer Agency SSP 6. 1 Is info normally shared? Which organizations, how is it accessed, and how is it used? X Support 6. 2 External sharing compatibility with SORN X Support 6. 3 Limitations on re-dissemination X Support 6. 4 External disclosure record maintenance X Support 6. 5 PIA Related to Information Sharing X Support 7. 1 Individual’s access to their information X Support 7. 2 Individual’s means for corrections X Support 7. 3 How are individuals notified about correction procedures? X Support 7. 4 PIA Related to Redress X Support Section 6. 0 Information Sharing Section 7. 0 Redress Advancing Government through Collaboration, Education and Action 14

PIA Sources RACI - 4 PIA Section (abbreviated) Customer Agency SSP 8. 1 Ensuring information used as in this PIA X Support 8. 2 Privacy training for users X Support 8. 3 User access determination procedures and how is access determined for individuals X Support 8. 4 Project reviews of information sharing requirements, MOUs, new information uses by internal and external organizations X Support Approval and Signature Page X Section 8. 0 Auditing and Accountability Advancing Government through Collaboration, Education and Action 15

Recommendation #3: Create a Standard SS Agreement/Contract Observation: Combination of Inter-Agency Agreements and MOUs are in use. A standardized Shared Services Agreement would reduce confusion, create a baseline and help manage expectations of both the Providers and Customers. Clauses for Consideration/Inclusion • Ownership - Customer is responsible and accountable for preparing the SORN and PIA for their data. • Audit and Inspection Rights - Specify the agency’s right to audit and inspect the Provider’s facilities and equipment which stores the Customer’s data. • Termination Rights and Disposition of Data – Address termination rights, what will happen to stored data at the conclusion of the agreement and the format in which the data will be returned to the agency or its designee. • Litigation - Should litigation arise that requires the agency to engage in preservation, search and/or production of data stored by the Provider, it is imperative that accommodations for e. Discovery are included in the interagency agreement. The contract terms, at a minimum, should establish the agency’s sole and absolute ownership and control over the data, the ability to apply search terms and the capacity to undertake preservation as necessary by custodian. • Indemnification for Losses Caused by the SSP - The contract should include a defense, indemnity, and hold harmless provision to protect against issues which include, but are not limited to, legal holds and sanctions which could arise from the Provider’s failure to properly preserve information. • e. Discovery Process - The interagency agreement should also address the Provider’s ability to document and report upon chain of custody and collection to assist with discovery and evidentiary concerns. In addition, the agreement should specify the processes and procedures that will be followed should the Provider be served with a legal request for the agency’s information. Advancing Government through Collaboration, Education and Action 16

Discussion Topics: PIA/SORN • In cases where a particular function is completely outsourced, is there any impact on the data ownership? – Use Case 1: Agency X outsources all of their procure to pay chain including invoicing, payment, and disbursement. Does data accountability change? – Use Case 2: Agency Y outsources the payroll function. Does data accountability change? Advancing Government through Collaboration, Education and Action 17

Issue #3 Compliance with Section 508 • • Section 508 of the Rehabilitation Act of 1973 (29 U. S. C 794 d), as amended, requires that agencies' Electronic and Information Technology is accessible to people with disabilities. While guidance on Section 508 has been issued by OMB and GSA, for example, what an agency needs to do to be compliant is interpreted differently by agencies. Customer agencies moving to FSSPs expect to be able to rely on them for compliance with federal requirements within their scope of service. Due to the varying interpretations of how to be compliant with Section 508, some CFO Act agencies looking to move to an FSSP may have more requirements for compliance than the FSSP currently performs, creating an actual or perceived gap in service. Advancing Government through Collaboration, Education and Action 18

Section 508 Compliance in a Shared Environment Challenges Findings • • • In 1998, Congress amended the Rehabilitation Act of 1973 to require Federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities Section 508 bars Federal agencies from procuring E&IT goods and services that are not fully accessible to people with disabilities VPAT, or Voluntary Product Accessibility Template, is a document that explains how accessible a product or service is. The VPAT was created so that federal agencies could compare vendors to determine which product or service is most 508 Compliant What an agency needs to do is subject to interpretation Customer agencies assume FSSP systems are Section 508 compliant, yet they retain responsibility • • • Policies (504 & 508) are subject to interpretation - leads to varied, inconsistent adoption Agencies and individuals have different needs System vendors typically adopt their commercial solutions for government use Agencies rely on vendors for compliance testing/proof and documentation (VPAT) Individual accommodations are not always known or easily anticipated & accommodated Guidance on a standard remediation process is required – for use by agencies and the IT industry Advancing Government through Collaboration, Education and Action 19

Section 508: Leverage Shared Services to Drive More Consistent Implementation 1. Leverage Shared Services to Reduce Number of Non-Compliant Systems – 1. Agencies & Individuals Have Different Needs – 2. Vendors Adopting Commercial Solutions – 2. 4. Inconsistent Procurement Compliance 3. Reliant on Vendors for Compliance Strengthen Procurement Guidance – – 3. Vendors adopting commercial systems for government use (e. g. , Microsoft Word and Google Docs) Agency Section 508 coordinators say it is problematic for agencies to use a shared service when that product has already been determined to not be compliant with Section 508 Too big a task for agencies to change tools after investing in deployment and training Acceptance should be based on testing outcomes (not just VPATS) Ensure the accessibility of the delivered product or service is maintained, or even improved, during the course of the contract Promote DHS Trusted Tester Program for Buyers & Sellers – – – Having certified trusted testers will relieve inconsistent Section 508 adoption DHS has funding to create testing results for different products, making it available to agency’s doing market research – helps avoid testing same things over and over! Approach supported by the Federal CIO Council Accessibility Community of Practice (https: //cio. gov/about/groups/accessibility-cop/) 4. Create a remediation process and ownership determination – 5. For COTS need a pre-defined process and method for determining responsibility for remediation in cases where there is a stakeholder that requires additional accommodations Create Use Cases for Various Real-life Situations – Assist Agencies in Dealing With Compliance Complexities Advancing Government through Collaboration, Education and Action 20

Observations for Promoting Accessible Shared Services 1. New Software Delivery Models Complicate Section 508 Compliance • Agile/Continuous deployment means software is deployed daily and weekly, requiring more testing and potentially requiring a different approach to testing and remediation • Challenges for software vendors to keep up and validate testing with frequent and unknown changes to the browsers and other accessibility technology 2. Trusted Tester Establishes Standardized Testing Approach • There has never been a federal government testing center for Section 508 product compliance • Having certified trusted testers will relieve inconsistent Section 508 adoption – Creates a standard testing methodology for use by government and industry • DHS has funding to create testing results for different products, making it available to agency’s doing market research – helps avoid testing same things over and over! • Approach supported by the Federal CIO Council Accessibility Community of Practice (https: //cio. gov/about/groups/accessibility-cop/) 3. Acceptance should be based on testing outcomes (not just VPATS) • Agencies are responsible for doing adequate market research and not solely relying on vendor published documentation – require testing via the Trusted Tester Program • Threat of non-compliance is currently not a significant driver for behavior change Advancing Government through Collaboration, Education and Action 21

Discussion Topics: Section 508 • Does increased documentation have a positive return on investment? – Forcing vendors to produce documentation ensures that they will perform the tests. – Creating and maintaining this voluminous documentation will increase costs considerably. Will the documentation actually be used to justify that cost increase? – Could more detailed SLA that defined accountability and expectations on remediation achieve the same outcome? • Do new support policies of the browsers (reactive vs. proactive) impact the best way to handle Section 508; should the government go more towards the reactive model? Advancing Government through Collaboration, Education and Action 22

PROJECT INFORMATION Advancing Government through Collaboration, Education and Action 23

Project Team Susan Smoter Project Co-Chair Hewlett Packard Enterprise Gavin Martin Project Co-Chair Professional Scientific and Technical Services LLC Stephanie Mango FMISSS COI Chair CGI Federal Inc. Jonathan D. Addelston FMISSS COI Vice Chair Up. Start Systems, LLC Don Perry AT&T Brian Lenane CGI Federal Inc. Ravindra Gupta Grant Thornton Advancing Government through Collaboration, Education and Action 24

Project Timeline & Impacts Initiation • 1/4/16 - Kick. Off Session • Team Building & Organization Interviews • 1/14/16 - Started • 1/29/16 - Ended Project Findings • 2/25/16 - Sponsor Validation • 3/25/16 – Interim Report • 5/15/16 - Final Report Given this timeline, the project leaders determined the best use of time was to focus on producing value-add outcomes by identifying gaps in the current processes and recommending feasible policy changes and tool updates to address problem areas. Nine interviews were conducted in January 2016 with an even split between service providers and agency customers. The team posed questions designed to validate project starting assumptions (see next slide on our methodology). We have included in this report additional findings beyond the project’s directive focus on System of Record Notification (SORN), Privacy Impact Assessment (PIA) and Accessibility (Section 508). Our team did not have time to complete this other work and we recommend it be included in a follow-up ACT-IAC project. Advancing Government through Collaboration, Education and Action 25

Shared Services Policy Project Methodology • Using initial examples provided, hypotheses of issues pointed to: – A need to clarify/expand Shared Services definitions to ensure consistent understanding by both agency customers and shared service providers Result: Data Ownership Inter-Agency Agreement (IAA) clauses recommended – Further expand the initial set of roles and responsibilities, incorporate into the FAME 2. 0 process – essential to effectively set and manage expectations Result: RACI mapped to FAME 1. 0 and 2. 0 (M 3) – Fill testing gaps for Section 508 compliance – buyer of shared technology; either provider or customer Result: Clarify Provider’s responsibility for compliance in FAME 2. 0 and RACI • Conducted interviews to validate project staring assumptions • Adjust in accord with findings • Publish results and share with stakeholders Advancing Government through Collaboration, Education and Action 26

Shared Services STARTING CHECKLISTS, USE CASES, AND QUESTIONS FOR FURTHER GUIDANCE OR POLICY DEVELOPMENT Advancing Government through Collaboration, Education and Action 27

Requirements Type Checklist Functional o Audit and Control (may be a functional requirement) o What are the consequences of different reporting requirements on data sets, data details, derived computations, time periods, formats, and different oversight roles involved? Non-Functional o External Availability, Installability, Integrity (against data inaccuracy and loss), Interoperability (see also Information Exchange models); Integration with other systems, interdependence; Use of existing product interfaces and APIs, Network Connection; Performance; Reliability; Robustness; Security (cybersecurity) o Internal Accessibility and User Interface (including branding); Efficiency; Modifiability; Reusability; Scalability; Verifiability This Requirements Type Checklist can be used to ensure each type is included in the agreements between the SSP and the customer, including Service Level Agreements (SLAs) Based on Software Requirements, Third Edition, by Karl Wiegers and Joy Beatty (2013) and The Requirements Engineering Handbook by Ralph R. Young (2004). The second has only a minor comment. Advancing Government through Collaboration, Education and Action 28

Use Case Table: SSP Types and Customers Shared Service Provider (SSP) Customers Federal Agency Any Federal Agency (Internal and External) Federal Agency Only Internal Agencies, Mandated Federal Agency Only Internal Agencies, Optional Federal Agency External Federal Agencies; issues about attaining scalability for success Commercial Organization Any Federal Agency Commercial Organization Specific Federal Agencies or Types • This use case table key combinations of SSP and Customer types that need to be considered for policies and implementation guidance. • Interviews revealed differing levels of attention being paid to guidance in FAME and other materials. • Providers with multiple customer agencies may have increased vulnerability and more entry vectors. Customer agency vulnerabilities may make providers vulnerable. • How do cost recovery constraints affect the growth rate of the customer agencies for FSSPs? Advancing Government through Collaboration, Education and Action 29

Use Case Table: Shared Services Model Customer Agency SSP Infrastructure / Cloud Services Provider Browser(s) Application Dynamic Resources Assistive Technology Utilities Storage Management Middleware Network Management Operating Systems Cybersecurity Local Networks Infrastructure Management Cybersecurity Data Entry / Data Feeds Application Users Applications Users (outsourced) SS Administration Custom Interfaces / Integration This Use Case Table shows a distribution of services that can be allocated to the roles in the columns. Some services can be moved to the right to produce different combinations to be considered. Infrastructure / Cloud Services Provider is generic, independent of the SS applications provided. Shared Services Administration includes Ch. M, Backup, Recovery, COOP, etc. Advancing Government through Collaboration, Education and Action 30

Use Case Table: SORN / PIA / S 508 Role SORN PIA S. 508 Reqts. S. 508 Test Customer Responsible Final User Acceptance Access Control Requirements Specific Requirements IV&V of SSP Assistive Tech Requirements SSP Shared Service Vendor Expertise N/A Expertise General Requirements SSP User Acceptance Access Control Requirements Specific Requirements IV&V of Vendor Assistive Tech Specifications Trusted Tester Methods Assistive Tech Implementation Integrated Testing Proof Section 508 Implementation Trusted Tester Methods Access Control Implementation This Use Case Table shows responsibilities related to the three policy areas, for the Customer Agency, the SSP, and the Shared Service product vendor(s) which can occur in different combinations. At stages in its lifecycle, an SSP’s systems may be in/out of Section 508 compliance. Advancing Government through Collaboration, Education and Action 31

Questions about Outsourcing Functions What are the consequences reflected in policy and guidance of outsourcing these functions from the customer to the SSP? (More study is needed) • Data entry • Reporting • Transaction Processing • Users external to the customer agency: contractors, public, unidentified users • Internal and External (Public) Help Desk Support • Use of additional third party providers Advancing Government through Collaboration, Education and Action 32

Data Management Checklist This checklist can be used to identify key activities to be allocated between the Customer Agency and SSP (or shared), as recorded in MOUs, IAAs, Contracts, and SLAs • • • Data Aggregation from the customer to the higher-level organizations that receive access to its data (e. g. , a Department Component has its data aggregated by its Department) Conversion; transition to SSP; consolidation of systems Transaction Logging Backup Recovery COOP, including Disaster Recovery Data Loss Data Security Data Mart Data Warehouse Archiving Special handling for classified data, including SBU Advancing Government through Collaboration, Education and Action 33

External Request Source Checklist Data Ownership by the Customer Agency implies that the SSP should pass any external requests for information back to the Customer Agency. This checklist can be used to ensure each case is considered and recorded, as appropriate, in the MOUs, IAAs, Contracts, and SLAs • Office of the President, including OMB • Congressional (testimony and GAO) • Audit Groups (Inspectors General, DOJ, FISMA Audits) • Leadership (superior agency leaders) – Aggregated reports and analysis across multiple agencies • • • Individuals included within the system (PIA) Privacy Offices National Archives FOIA requests Court Orders Advancing Government through Collaboration, Education and Action 34

Accessibility Status Use Case List The following questions need to be considered in the agreements between the Customer Agency and the SSP, related to accessibility and Section 508 compliance. More analysis is needed and additional questions may be developed. The variations in the accessibility conditions may be reflected in policy and guidance: • What are the differences which occur when the customer agency has inadequate accessibility verification and validation (testing) capability? • What are the consequences (which are likely to occur) when the customer agency has specific accessibility requirements which differ from the support provided by the SSP? • What are the consequences depending on the existence, approval, and content of an approved (standard? ) list of assistive technologies? Which parts of the process are affected within the acquisition and shared services life cycle? Advancing Government through Collaboration, Education and Action 35

Questions about Agreements Answers to these questions need further research and analysis, to ensure that their potential influence on policies and guidance are understood • This reports cites MOUs, IAAs, contracts (between the government and commercial providers), and SLAs. Are other types of agreements used for shared services? • What topics should be covered in each type of agreement? • What risks occur, if a topic is omitted or incompletely covered? • What are the adverse consequences if a topic is moved to a different agreement type or covered in multiple agreements? • What are the consequences if key requirements are omitted from, or inadequately specified, within the contractual documents establishing interrelationships between the key roles of the SSP, Customer Agency, Shared Service Vendors, and other key organizations? Advancing Government through Collaboration, Education and Action 36

Shared Services Support Functions Checklist What are the potential effects on shared services effectiveness (value to the customer) and efficiency (costs and return on investment) based on variations due to responsibility allocation between SSP, Customer Agency, Other Government Organizations (e. g. , Trusted Testers), Shared Service Vendor, and additional contractors for: – Process Improvement – Acceptance Testing – Accessibility / Section 508 claims – Maintenance Repairs, including upgrades – Computer Systems Operations – Configuration Management – Cybersecurity: Vulnerability analysis, attack analysis and defense, post event analysis (forensics), remediation – Data Integrity – Verification and Validation (including potential IV&V) Advancing Government through Collaboration, Education and Action 37

Life Cycle Document Checklist To what extent do each of these documents support the SSP process for engagement between the Customer Agency and the SSP? What are the risks and adverse consequences if these are not produced or inadequate? • • • • SSP Plan (e. g. , inaccurate claims of Section 508 compliance) SSP Service Level Agreement (SLA) RFI for Shared Services (e. g. , Section 508 market research) RFP for Shared Services (e. g. , changing requirements impact) Shared Service Product Description and Warranty Shared Service Test Plan and Results (related to Section 508) Shared Service Product Proposal (OEM) Proposal from Vendor Customer Agency Contracts with commercial SSPs Vendor Contracts to SSP MOU between agencies IAA between agencies SLA between the participating organizations Disability Support Requirements; compliance from SSP product Disability Support Requirements for specific customer agencies Advancing Government through Collaboration, Education and Action 38