A0007_RFP Attachment 1 - Base PWS.docx

APPS

Appian Platform and Product Support ITS SPS Performance Work Statement for Appian Platform and Product Support RFP Version 1.0 ITS Supervision & Platform Support (SPS)

BPAS

Business Process Automation Systems ITS SPS

A-1

Document Control

Contents

APPS

Appian Platform and Product Support ITS SPS

Introduction Scope of Work This is an indefinite delivery/indefinite quantity (IDIQ) contract (see FAR 16.5) that allows the placing of individual task orders against this base contract. The scope of this IDIQ contract includes all services necessary to provide support for OCC’s Appian software platform activities. Tasks may include, but are not limited to:

a. Program/Project Management

i. Program/Project Management and Contract Management. E.g., Status Reports; Project Planning; Release Panning; Periodic (Monthly, Quarterly, etc.) Reviews; Key Performance Indicator (KPI) Tracking and Reporting.

ii. Contract and Product Transition Planning and Management. E.g., Transition Planning; Transition Scheduling Creation/Management; Transition Execution; Transition Status Reporting; Phase-in/Phase-out Support.

iii. Quality Control (QC) Management. E.g., Creating and Maintaining a Quality Control Plan; Collaborating and Cooperating with OCC on Surfacing Quality Issues.

b. Software Lifecycle Functions

i. Operations, Compliance, and Business Investment. E.g.:

A. Creating and maintaining platform and product architectural roadmaps;

B. Monitoring and documenting product tool version levels;

C. Creating and maintaining SDLC documentation for OCC products;

D. Analyzing and resolving software defects reported;

E. Modifying existing software to resolve reported system problems;

F. Managing the configuration of new and modified system software;

G. Designing, testing, and deploying new system software (including inbound and outbound interfaces);

H. Repairing and recovering data for OCC systems; managing OCC data in transit until it is received by its destination system;

I. Implementing process improvements associated with specific maintenance activities;

J. Requirements Gathering and Analysis;

K. Technical Design and Validation;

L. Testing;

M. Knowledge Transfer/Training;

N. Use the Specific Set of Contemporaneous Development Tools Required by OCC;

O. Create, Maintain, and Implement Product-Specific Development Standards;

P. Establish the Baseline Security Architectures.

Q. Create and Maintain Documented Standards for Secure Maintenance;

R. Security Analysis;

S. Create and Maintain Documentation.

ii. Configuration and Release Management. E.g., use of Configuration Management Plans to maintain a configuration-management approach; Version Compliance Reporting; Tool Version Reporting; Create and maintain Artifact-Update Checklists; Build Testing; Release Build and Deployment; Manage Code Baselines.

iii. Technology Refresh, Architecture Support, and Research. E.g., Create and maintain architectural roadmaps; Conduct gap analyses; Technology research; Participate in integrated system engineering teams; Analyze and document functional and technical requirements; Conduct systems analysis; Identify possible technology improvements.

iv. Product Testing, Training, and Implementation. E.g., User Acceptance Testing; Training; Organizational Change Management Planning and Communication; Develop implementation strategies.

v. Patches and Upgrades. E.g., Security patch reporting; security patch updates; Maintain product environments to include any required third-party software; Upgrade and retire software products (to include required third-party products).

vi. Other System Maintenance. E.g., Trend Analysis, Defect Tracking, Optimization, Performance Metric Reports, Product Audits, Cloud Migration and Support.

c. Systems Operation

i. Tier-2 and Tier-3 Help Desk Support. E.g., Respond to Help Desk incidents; Respond to Help Desk service requests; Resolve customer issues; Resolve production incidents; Create and maintain product support Knowledge-Base Articles (KBAs); Escalating incidents; Post-incident review, analysis, and mitigation plans.

ii. Product Monitoring and Recovery. E.g., Create and maintain comprehensive product monitoring plans; Product monitoring incident reporting; Use OCC monitoring tools to implement product monitoring plans.

Furthermore, this IDIQ contract establishes a framework to provide services for the planning, analysis, architecture, design, development, testing, implementation, and operation & maintenance of products or tools developed on the Appian software platform. This includes integrations with, or the deployment of, associated software such as Appian or third-party plug-ins, artificial intelligence modules, and other software components necessary to meet business needs. The Contractor must provide support for a gambit of small and simple projects as well as major and complex projects, and everything in between. As OCC’s needs evolve, it is anticipated there will be continuous addition of new products using the Appian platform and possible decommissioning of others. The only known new product to be developed under this contract at the time of the writing of this IDIQ is Examiner Portal (ExPo) which will be a major complex project. The Contractor is tasked with building Appian solutions tailored to OCC’s requirements, implementing these solutions, as well as ensuring their smooth operation, ongoing maintenance, and phase-out/decommissioning of the solution as required. This involves routine updates, addressing software defects, and implementing any essential enhancements to ensure the product's performance, security, and applicability. This will require the Contractor to work closely with both government staff and other OCC contractors to ensure the successful implementation of new products, especially larger enterprise-wide systems (e.g., ExPo). To meet this requirement, the OCC may require the Contractor to sign contractor-to-contractor nondisclosure agreements or request the OCC coordinate the same with its other contractors, as appropriate. In the event another (e.g., existing) OCC contractor refuses to sign a nondisclosure agreement with the Contractor, the OCC will coordinate with the Contractor to determine if there is an alternate way to perform the associated work. The OCC shall not be a party to any nondisclosures signed between contractors (e.g., a tripartite) unless the contracting officer explicitly certifies (e.g., signs) to such in writing. By harnessing the strengths of the Appian platform, OCC’s goal is to realize efficient, enduring, and adaptable software solutions in line with its organizational goals. Travel may be required on task orders against this IDIQ contract. If travel is authorized for reimbursement, it must be specifically stated and addressed at the task order level. Task orders may be issued under this IDIQ contract using statements of work (SOWs), performance work statements (PWSs), and statements of objectives (SOOs) to communicate requirements and elicit a quotation or proposal from the Contractor.

Overview of Services The primary objective of this IDIQ contract is to ensure continuous, effective support of the OCC’s Appian platform. This includes operations and maintenance of existing products as well as the development of future products built on the platform. The secondary objective is to enhance the quality-of-service delivery while increasing customer satisfaction levels. Work under this contract must be conducted in alignment with these overarching objectives and must be laid out in more granular detail under each task order issued. Work under this contract spans operations, compliance, and business investment activities—in that order of priority.

This IDIQ contract and/or its task orders will have references to existing OCC platforms (e.g., eDocs, Rational JAZZ), products, services, and technologies that integrate with or are used by the Appian platform. The OCC may choose to replace these platforms, products, services, and technologies during the period of performance; the Contractor must continue to support integrations with the replacement tools.

Accelerators and Software Licenses The Contractor must use OCC’s existing Appian platform licenses to build and maintain products under this contract. There may be situations in which supplemental software needs to be purchased by the Contractor from the Appian App Market which provides Solutions, Plug-Ins, and other software components that streamline development, enhance interoperability, and provide a comprehensive environment for Appian product development and deployment. Any materials purchased by the Contractor shall become property of the OCC and must remain as government property. The categories of software licenses that may be purchased include:

· Solutions: Pre-built application structures designed to speed up the development process. They come with reusable elements such as forms, process workflows, and dashboards that can be configured to meet specific product requirements.

· Plug-Ins: Appian provides a wide range of connectors that facilitate seamless integration with other systems, both on-premises and in the cloud.

· Other Third Party-Software: Additional software tools (e.g., shell scripts) specifically built for Appian integrations. Some, but not all, of these tools are available in the Appian App market.

One category of license that is excluded is Appian base product licenses (e.g., Appian named user licenses, Appian robotic process automation licenses, Appian process automation licenses).

The OCC will download and make available to the Contractor all needed non-cost solutions / accelerators, plug-ins, and third-party software.

The contract may require the Contractor to buy varying quantities and types of software components over the contract's ordering period, aligned with evolving project requirements and technical needs. On task orders, this will be billed to a time and materials (T&M) contract line-item number (CLIN) with this express purpose.

The Contractor must only provide the OCC with Appian software components that come with a perpetual-use license; all licenses must be registered to, and become property of, the OCC (i.e., they will be considered materials under any task orders issued against the IDIQ contract). In uncommon circumstances, the OCC’s contracting officer (CO), and only the CO, may approve the Contractor to provide OCC with licenses that are not perpetual-use licenses (i.e., term licenses). The Contractor must receive CO approval of subscription or term licenses when needed. This shall ensure:

· Full Control: The Government has full control over the software, allowing for unlimited use within the bounds of the contract and the underlying commercial supplier agreement (i.e., software license), without recurring licensing fees.

· Transferability: The Government retains the right to transfer these licenses across different departments or projects (within the terms of the commercial supplier agreement), ensuring maximum utility and flexibility.

The Contractor must coordinate and gain approval from both the COR and the CO for all software purchases and must follow OCC processes and procedures for any software purchased under any task order. This includes, but is not limited to, ensuring that all software licenses purchased are compliant with OCC's procurement policies, legal requirements, and contract language stipulations (e.g., terms & conditions). The Contractor must include the necessary contract language specified by OCC when procuring software licenses, ensuring that all terms, conditions, and deliverables align with OCC standards and policies; the COR will provide specific language to be incorporated and/or any flow down of clauses from this OCC contract to the Contractor after consultation with the CO. The Contractor must request CO approval and gain CO approval of any final language for incorporation into any subcontract for software purchases prior to the Contractor finalizing any software purchase for the OCC under this contract.

Place of Performance The OCC may require the Contractor have employees (some, all, or none) work at the Government site (OCC Headquarters) or at the Contractor site. The OCC may require a mixed arrangement with some, all, or no work required to be performed at the OCC Headquarters or Contractor’s site. Further details on place of performance and any telework will be detailed in each task order. If a task order does not explicitly address telework (due to omission or otherwise), the CO may allow telework under the task order upon contractor request (and COR concurrence with the request), and solely at the CO’s discretion. The Contractor must ensure sufficient staffing as agreed in each task order, whether virtual or on site, during contract core hours of operation between 9:00 a.m. to 5:00 p.m. ET (Eastern Time). Task orders may require work outside of core hours.

ICT Accessibility Requirements Section 508 of the Rehabilitation Act, as amended by the Workforce Investment Act of 1998 (P.L. 105-220) requires that when Federal agencies develop, procure, maintain, or use information and communication technology (ICT), it shall be accessible to people with disabilities. Federal employees and members of the public who have disabilities must have access to, and use of, information and data that is comparable to people without disabilities. As such, the following requirements apply to this solicitation:

1. Products, platforms, and services delivered as part of this work statement that are ICT, or contain ICT, must conform to the Revised 508 Standards, which are located at 36 C.F.R. § 1194.1 & Apps. A, C & D, and available at https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines

1. E102 / 702.10 – Web Content Accessibility Guidelines (WCAG) success criteria level A & AA are incorporated as a requirement. The referenced WCAG criteria is available at http://www.w3.org/TR/WCAG20/

1. A completed Accessibility Conformance Report (ACR) found at https://www.itic.org/policy/accessibility/vpat, using Voluntary Product Accessibility Template (VPAT) Revised Section 508 Edition, Version 2.4, is required to assist the Government in determining that the ICT products or services support Section 508 accessibility standards.

1. E202 –General Exceptions as Authorized by OCC.

The following items are identified as containing ICT: Appian Platform and Product Support (documents, reports, etc.)

· Software Applications & Operating Systems

· Web-based Intranet and Internet Information and Applications

· Information, Documentation, and Support

Applicable Functional Performance Criteria: All functional performance criteria apply when using an alternative design or technology that achieves substantially equivalent or greater accessibility and usability by individuals with disabilities than would be provided by conformance to one or more of the requirements in Chapters 4-6 of the Revised 508 Standards, or when Chapters 4-6 do not address one or more functions of ICT.

Applicable requirements for software and Web products:

· E207 – WCAG Level A & AA Success Criteria

· E302 – Functional Performance Criteria

· E502 – Interoperability with Assistive Technology

· E503 – Application

· E504 – Authoring Tool

· E501 – Web-based applications, independent of platform services Applicable requirements for electronic documents and/or support services:

· E205 – WCAG Level A & AA Success Criteria

· E302 – Functional Performance Criteria

· E602 – Support Documentation

· E603 – Support Services Section 508 Compliance for All Electronic Document or Report Deliverables The Offeror shall adhere with the OCC Best Practice Guide for Crafting 508-Compliant Word/PDF Documents (see attachment PWS Annex A) to produce all electronic document or report deliverables.

Agile Development and Appian Platform & Product Background and Additional Requirements This section describes specific details about the SPS Agile approach and background information for each of the existing and known future products and platforms in the PWS. See Annex B, for details.

Staffing Key Personnel Certain skilled and experienced professional and technical personnel are essential for successful accomplishment of the work included in this IDIQ contract. Section 2 provides background about the work of the OCC business units supported under this PWS. Section 2 describes the associated products, processes, and the product-specific needs. This information provides the Contractor insight into the skills and experience required to support the scope of work outlined in Section 1.

Minimum Qualification for IDIQ-Level Key Staff

Program Manager The Contractor’s Program Manager shall be accountable to the OCC for the overall management and coordination of all task orders, in aggregate, issued under this IDIQ contract and shall act as the direct supervisor for all the Contractor’s Project Managers on the task orders issued against this IDIQ contract. The Program Manager must be included as a resource in every task order issued under this IDIQ contract.

Program Manager Required Qualifications The Program Manager must have at least 7 years of demonstrated ability leading and simultaneously managing multiple projects. This includes managing and completing at least two projects using Agile methodologies with at least 20 personnel directly working on the projects under their management in a professional setting.

Ideal/Preferred Program Manager Knowledge, Skills, and Abilities (not required):

The ideal program manager will have experience in various areas of program management including IT knowledge, project management, leadership, communications, risk management, financial management, contract management, problem solving and customer relationship management. Beyond the required qualifications, the ideal Program Manager would have:

1. strong leadership and management skills as a Program Manager leading cross-functional teams, coordinating with multiple stakeholders, and making critical decisions;

2. proficiency in project management methodologies and tools which is crucial with Agile development and project management experience;

3. excellent communication skills, both written and verbal, which are essential for conveying project status, issues, and solutions to team members, clients, and executives;

4. experience in identifying and managing risks associated with IT projects and contracts;

5. familiarity with contract management, including legal aspects and compliance, particularly managing contracts with governmental organizations or highly regulated industries;

6. strong problem-solving and decision-making abilities for addressing issues that may arise during the contract;

7. experience building and maintaining strong client relationships; and

8. financial management experience equivalent to the size and complexity of this IDIQ contract.

Additional key personnel and updated minimum qualifications may be negotiated and required under each task order.

Predefined Labor Category Qualifications (Non-Key Positions) Under any task order issued, the labor categories in this section (3.3) must meet the associated minimum qualifications unless otherwise stated in the task order. Task orders may require labor in categories not listed in this section as long as they are in direct support of the activities listed in Section 1.1 “Scope of Work.” Pricing and availability of labor categories not listed in this section shall be negotiated at the task order level.

Appian Technical Lead/Architect The Appian Technical Lead must:

· Have an Appian Lead Developer certification.

· Two or more years of professional development experience on the Appian platform

· Two or more years of professional experience in Agile development and software lifecycle planning

· One or more year of professional experience in project management, including status reporting, resource planning, creating sprint/release integration plans, etc.

Appian System Administrators All resources serving in the Appian System Administrator role shall meet the following qualifications:

Education:

· Bachelor’s degree in Computer Science, Information Technology, or a related field.

Experience:

· At least two years of experience working with Appian, including development or configuration, with exposure to system administration tasks such as monitoring, security, and maintenance. While direct experience in supporting Appian environments in a system administration role is strongly preferred, which includes system configuration, monitoring of performance and troubleshooting technical issues, candidates with strong technical skills and adaptability in platform administration will also be considered.

· At least two years of experience in general system administration, supporting platforms such as Windows, Linux, or cloud infrastructure, with a preference for experience integrating enterprise systems (ERP, CRM, RDBMS, etc.).

Certifications (Required):

· The candidate must, within 6 months of onboarding any task order, either:

· obtain the Appian Certified Senior System Administrator certification; or

· complete the Appian-provided learning path training for Appian Administrator (instructor lead - 4 half days) as a substitute for this requirement.

Certifications (Preferred):

· Appian certifications (e.g., Appian Certified Associate Developer, Appian Certified Lead Developer, or Appian Certified Senior System Administrator) are highly desirable.

· Relevant IT certifications, such as AWS, Azure, ITIL, or security-related certifications, are a plus.

Appian Senior Developers All resources serving in this role must:

· Possess an Appian Senior Developer certification. Appian Corporation developers proposed by the Contractor may have different certification paths than those available to partners and customers. For these developers, the Contractor shall provide a description mapping their qualifications to the equivalent certifications outlined in this document (e.g., successful completion of the Appian Academy program and a minimum of 2 years of relevant development experience).

· Have at least 2 years of Appian development experience and have passed the Appian Academy.

Appian Junior Developer All resources serving in this role must:

· Possess an Appian Associate Developer certification. Appian Corporation developers proposed by the Contractor may have different certification paths than those available to partners and customers. For these developers, the Contractor shall provide a description mapping their qualifications to the equivalent certifications outlined in this document (e.g., successful completion of the Appian Academy program and a minimum of 6 months of relevant development experience).

· Have at least 6 months of Appian development experience and have passed the Appian Academy.

Database Developers All resources serving in this role must:

Have one or more years of professional experience in database development in Microsoft SQL in a professional environment.

Have one or more years of professional experience using database comparison/script packaging software such as SQL Server Data Tools, RedGate SQL Compare, or any other similar tools.

Quality Assurance Lead All resources serving in this role must:

Have two or more years’ experience using an enterprise test management suite such as Rational Tools, Azure Test Plans, or other equivalent platforms for functional and performance testing.

Have two or more years’ experience performing in a configuration management role.

Have two or more years’ experience performing in a help desk support role.

Quality Assurance Resource All resources serving in this role must:

Have one or more years of professional experience using an enterprise test management suite such as Rational Tools, Azure Test Plans, or other equivalent platforms for functional and performance testing.

Have one or more years of professional experience performing in a configuration management role.

Have one or more years of professional experience performing in a tier 1 or tier 2 help desk support role.

Have one or more years of professional experience in automated and performance testing.

Agile Coach Any resource serving in this role must:

· Have at least two of the following relevant Agile certifications: Certified Agile Coach (CAC), IC Agile Certified Professional in Agile Coaching (ICP-ACC), Certified ScrumMaster (CSM), Certified Scrum Professional (CSP), Agile Certified Practitioner (PMI-ACP), Certified Agile Leadership (CAL).

· Have over five years of experience, in a professional environment, with Agile methodologies, such as Scrum, Kanban, Lean, or others.

· Have at least 3 years of experience, in a professional environment, coaching teams and organizations in Agile practices, including helping teams understand and implement Agile principles, roles, and ceremonies.

· Have at least 3 years of experience, in a professional environment, in leadership and facilitation in guiding teams and organizations through the Agile transformation process.

Business Analyst

Any resource serving in this role must:

· Have at least three years of experience in business analysis or a related field, preferably within IT services or software development environments.

· Have at least three years of experience demonstrating the ability to define, document, and validate business and functional requirements in a structured and traceable manner.

· Have at least two years of experience with process modeling, workflow analysis, and requirements gathering techniques such as workshops, interviews, and use case development.

· Have at least two years of experience working within agile, iterative, or other project management methodologies and familiarity with Azure DevOps, JIRA, Confluence, or similar tools for tracking requirements and project progress.

Project Manager Any resource serving in this role must:

Have three to five years of professional project management experience. This experience should include proficiency in project management software, budgeting, financial management, and risk management which is essential. Additionally, experience in stakeholder management, negotiation, conflict resolution, and a commitment to continuous improvement through Agile methodologies are highly valued.

Have a Project Management Professional (PMP) certification from the Project Management Institute (PMI).

Incentive Structure Template for Task Orders

1. Incentives. Task orders may include incentives and/or disincentives.

2. Application. Incentives/disincentives, when included in a task order, will be applied in accordance with Tables 1 through 4. Major and non-major performance elements will be negotiated between the OCC’s Contracting Officer and the Contractor and clearly identified at the task order level.

3. Example/Illustration. Tables 1 and 2 are used by matching the quality (rows) of the performance element with the timeliness (columns) of the performance element using the definitions found in Tables 3 (quality) and 4 (timeliness). The incentive or disincentive to be applied for the applicable performance element is determined by the box in which the appropriate row and column intersect regarding the associated performance element. E.g., for a major performance element, medium quality, and fully compliant timeliness results in a $500 incentive.

Table 1. Major Performance Element Incentive/Disincentives

Timeliness2

1 See Table 3. “Quality Table” for definition of quality levels.

2 See Table 4. “Timeliness Table” for definition of timeliness levels.

Table 2. Non-Major Performance Element Incentive/Disincentives

Timeliness2

1 See Table 3. “Quality Table” for definition of quality levels.

2 See Table 4. “Timeliness Table” for definition of timeliness levels.

Table 3. Quality Table

High

Documents (Must meet ALL the following criteria)

1. Consistency in Documentation: Adheres to the standard documentation template and style guide with 95% or greater compliance. This includes uniform use of language, technical terms, and formatting across all documents; AND

2. Document Validation: Ensures 100% of facts, figures, and other data are validated with credible sources.

Software (Must meet ALL the following criteria)

1. Escaping Defects: Exhibits 0 critical production defects per product release within the first three months post-deployment;

2. Rollbacks: Requires no production rollback per six production releases; AND

3. Snapshot: Achieves 95% or higher of the agreed-upon functionality and performance metrics by the initially scheduled delivery date.

Medium

Documents (Must meet ALL the following criteria)

1. Consistency in Documentation: Achieves 75% to 94% compliance with the standard documentation template and style guide, including consistent use of language, technical terms, and formatting; AND

2. Document Validation: Validates 90% to 99% of facts, figures, and other data with credible sources.

Software (Must meet ALL the following criteria)

1. Escaping Defects: Exhibits between 1 and 2 critical production defects per product release within the first three months post-deployment;

2. Rollbacks: Requires one production rollback per six production releases; AND

3. Snapshot: Achieves 80% to 94% of the agreed-upon functionality and performance metrics by the initially scheduled delivery date.

Low

Documents (Meets ANY of the following criteria)

1. Consistency in Documentation: Fails to achieve 75% compliance with the standard documentation template and style guide, resulting in inconsistent use of language, technical terms, and formatting; OR

2. Document Validation: Validates less than 90% of facts, figures, and other data with credible sources, and lacks proper citations for significant portions of the data.

Software (Meets ANY of the following criteria)

1. Escaping Defects: Exhibits more than 2 critical production defects per product release within the first three months post-deployment;

2. Rollbacks: Requires more than one production rollbacks per six production releases; OR

3. Snapshot: Achieves less than 80% of the agreed-upon functionality and performance metrics by the initially scheduled delivery date.

Table 4. Timeliness Table

Fully Compliant

100% of contractual milestones are met on or before the due dates.

Partially Compliant

80-99% of contractual milestones are met on time with minor delays or issues within the contractor’s control that do not critically affect the overall project timeline or outcomes.

Non-Compliant

Less than 80% of contractual milestones are met, with significant delays or failures within the contractor’s control that critically impact the project's timeline and deliverables.

A-2 Security and Privacy Requirements A. Compliance with Applicable Laws, Regulations, and Standards Federal Laws. The contractor and all of its respective subcontractors shall follow and remain compliant at all times with the Federal Acquisition Regulation (FAR), Privacy Act of 1974 (5 U.S.C. 552a - the Act), Federal Information Security Modernization Act of 2014 (Public Law 107-347) (FISMA).

Privacy Act. As prescribed in the FAR 24.104, because the contract involves the design, development, or operation of a system of records on individuals, the contractor must implement requirements in FAR clause 52.224-1, “Privacy Act Notification” and FAR clause 52.224-2, “Privacy Act.”

In addition, the contractor is responsible for ensuring individuals supporting the OCC are trained in accordance with FAR clause 24.301, “Privacy Training.” The use of any information that is subject to the Privacy Act will be utilized in full accordance with all rules of conduct as applicable to Privacy Act Information.

FIPS. The contractor and all of its respective subcontractors shall follow Federal Information Processing Standards (FIPS), National Institute of Standards and Technology (NIST) standards and guidelines, and other laws, mandates, or executive orders pertaining to the protection of sensitive information and information systems.

OCC Enterprise Cloud Secure Communication Standards. All user-to-cloud service communications must be encrypted with the latest OCC-approved browser protocol.

OCC Policies and Procedures. The OCC understands that there are limitations in applying agency-specific policies to systems and environments shared with other organizations or customers. The requirements in this OCC Policies and Procedures subsection applies to all activities specifically performed for the OCC by the contractor (e.g., professional services to develop or customize a component for the OCC). The intent of this section is to require contractor compliance with OCC policies and procedures for those activities, tasks, and deliverables specifically and uniquely performed and/or completed for the OCC by the contractor that is not a typical service or component of the existing contractor system/solution. This section also applies to contractors with access and use of OCC information resources (i.e., OCC network, systems, laptops, other IT equipment, and/or OCC information).

The contractor and all of its respective subcontractors shall comply with all Office of the Comptroller of the Currency (OCC) security and privacy policies and standards in effect at the time of the award of the contract, as well as those requirements that may be added during the contract.

The contractor/service provider shall conform to OCC administrative regulations, policies, and procedures, as listed in the annex of section 2 and appendices of this document, in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. The contractor shall work with OCC internal organizations, as needed, to ensure that policies, procedures, configuration control, and product life-cycle requirements are fulfilled to the satisfaction of OCC ITS.

B. General Requirements Location. Information collected, used, stored, maintained, or otherwise processed by the contractor in the performance of this contract shall be accessed, transferred, stored or processed only within the United States. In addition, the maintenance and support operations of the contractor's technology and information must take place, and originate from, within the United States.

The contractor shall not host any portion of the information, information system, infrastructure, or environment in facilities outside the contiguous United States, Alaska, Hawaii, and other U.S. Territories.

Authorization to Use, Store, or Share Sensitive Information. The contractor shall be responsible for properly protecting all information used, gathered, or developed as a result of work under this contract. The contractor shall also protect all government data, equipment, etc. by treating the information as sensitive. All information gathered or created under this contract shall be considered as Controlled but Unclassified (CUI) information. It is anticipated that this information will be gathered, created, and stored within the primary work location. If contractor personnel must remove any information from the primary work area, they shall protect it to the same extent they would their proprietary data and/or company trade secrets.

Confidentiality. The contractor agrees to assume responsibility for protecting the confidentiality of government records and data associated with this contract, which are not public information.

Non-Disclosure Agreement. Each individual who has access to sensitive OCC data and/or the OCC network, systems, applications, laptops, or other OCC information resources that may process, store or transmit sensitive OCC data under this contract shall execute a Non-Disclosure Agreement before being allowed such access.

Deliverables. The deliverables in this contract will be considered CUI and shall not be shared with any other organization without prior written approval from the OCC CO.

C. Security and Privacy Authorization FIPS 199 System Security Category - FedRAMP. It is anticipated that the Federal Information Processing Standard (FIPS) 199 system security categorization for the Appian platform and products will be FIPS 199: Moderate. Since the Appian Cloud is a public cloud solution, the Federal Risk and Authorization Management Program (FedRAMP) Moderate control baseline, which is based on the Federal Information Security Modernization Act of 2014 (FISMA) security and privacy requirements for a Moderate impact system, applies to the contractor and the contractor systems supporting these public cloud services.

Authorization Boundary. The contractor shall provide a security architecture diagram(s) specific for the OCC, that clearly demarcates the information system authorization boundary and depicts all of its connections, ports, protocols, functions, services, and components, including the means for monitoring and controlling communications at the external boundary and at key internal boundaries within the system. The contractor shall address all components, connections, ports, protocols, security controls, and managed interfaces of the information system authorized for operation (e.g., routers, firewalls). The diagram must include a predominant border drawn around all system components and services included in the authorization boundary. If there are OCC-specific components (e.g., components developed or customized for the OCC, OCC-hosted components, etc.) and/or other components supporting this solution that are not in the scope of the contractor's existing security documentation, then identify those components in the diagram as well, as part of a separate OCC-specific boundary since those are unique to OCC and shall be part of the OCC-specific security authorization. The diagram must be easy to read and understand. Formal names of components as they are known at the service provider organization in functional specifications, configuration guides, other documents and live configurations shall be named on the diagram and described. The contractor shall provide a key for symbols used. This diagram shall be delivered to the Everbridge COR, Enterprise Architect, and Information System Security Officer.

Customer Responsibilities - FedRAMP. The contractor shall provide a detailed list of all customer responsibilities assigned to the OCC, as defined by the vendor and documented under each Federal Risk and Authorization Management Program (FedRAMP) package in the Customer Responsibilities Matrix (CRM) to be leveraged in the solution, as applicable.

For each customer responsibility, the contractor shall identify whether the contractor will be addressing the responsibility under the contract in order to fully meet the requirements specified in this PWS, or whether the responsibility will be assigned to the OCC. The contractor shall provide the CRM as directed in the "Security and Privacy Vendor Deliverables" section.

External Service Provider Compliance & Monitoring Background. The FISMA and OMB policies require that federal agencies using external service providers to process, store, or transmit federal information or operate information systems on behalf of the federal government, assure that such systems meet the information security protections commensurate with the information and system sensitivity. Federal agencies are responsible and accountable for the information security risk incurred by the use of information system services provided by external providers.

Such risk is addressed by incorporating the Risk Management Framework (RMF)1 and security requirements for external information systems and services as part of the terms and conditions of the contracts with external providers. Federal agencies can also require external providers to provide appropriate evidence to demonstrate that they have complied with protecting federal information. Prior to the implementation of the contractor's system or services, the OCC ensures compliance with the RMF by issuing an Authorization to Operate (ATO) or Authorization to Use (ATU), based on its review and analysis of the external provider's security documentation (described in detail in the next section) and assessment of customer (OCC's) security responsibilities.

1NIST Special Publication 800-37, as amended, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy.

FedRAMP Cloud Authorization Package. FedRAMP is mandatory for Federal Agency public cloud deployments and service models. Private cloud deployments intended and dedicated for single organizations are the only exception.

The contractor shall be responsible for obtaining a FedRAMP-approved Third-Party Assessment Organization (3PAO) to perform the following:

a. Initial IT security and privacy control assessment of the Appian Cloud

b. Annual IT security and privacy control assessment of the Appian Cloud on a subset of controls in accordance with the OCC Appian Cloud Information Security Continuous Monitoring (ISCM) Plan; and

c. Upon significant change to the Appian Cloud, full or delta assessment of the system depending on the degree and scope of the significant change.

The FedRAMP Authorization Package and its contents shall be developed in accordance with OMB A-130, FedRAMP, and applicable NIST SPs guidance. The contractor shall provide the FedRAMP Authorization Package resulting from each of these assessments and contents, as listed and per the frequency in the "Security and Privacy Vendor Deliverables" section, to support OCC's initial and Ongoing Authorization for the solution.

OCC Security Authorization to Use. The determination of whether to issue an OCC security authorization will be made by the OCC based on the identified risks to the OCC's data and operations. These risks include: (1) deficiencies noted in the FedRAMP Package(s), including weaknesses and associated risks identified in the most recent 3PAO Security Assessment Report and Plan of Action & Milestone and (2) gaps in OCC control responsibility (i.e., OCC's customer responsibilities per the CRM) implementation identified by the OCC Security Assessment Team and documented in the OCC SAR.

Ongoing Authorization. The contractor shall provide the OCC with access to all information and documentation needed to support the OCC's ongoing authorization for the solution and shall provide periodic status of risk updates per the frequency and instructions in the "Security and Privacy Vendor Deliverables" section, including:

a. Annual 3PAO Security and Privacy Assessment Report (SAR).

b. Open POA&M report included in FedRAMP Monthly Continuous Monitoring report (See Section E. Continuous Monitoring)

c. Annual System Security Plan (SSP) Update.

D. Configuration Management

Security Configuration Settings. The contractor shall establish and enforce security configuration settings for information technology products employed in the Appian Platform.

Security Updates and Patches. The contractor shall ensure that the Appian Platform and all Products is properly maintained and monitored, to include immediate response to critical security patches, routine maintenance windows to allow for system updates, and compliance with the defined configuration management and change control processes. All patches and system updates shall be properly tested in a development environment before being implemented in the production environment.

Least Functionality. The contractor shall restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services for information technology products employed in the Appian Platform.

Customer Design Specifications. The requirements in this Customer Design Specification subsection apply to OCC-specific components or customizations (e.g., components developed or customized for the OCC, OCC-hosted components, etc.). For such components, the contractor shall provide a Technical Architecture and Design Specification Document relating to the use of the Appian Platform, to include ports, protocols, services, interconnections to OCC and external systems, and supporting software. The contractor shall also detail any actions required by OCC or its customers, users, etc., to enable the installation, configuration, and/or use of the Appian Platform and provide the document to the OCC as directed per the "Security and Privacy Vendor Deliverables" section. The contractor shall configure these components using OCC-approved secure configuration settings and shall restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services on these components.

E. Continuous Monitoring

The contractor shall support the OCC ISSO by providing access to all required information and documentation to support the OCC's ongoing authorization process. Specifically, the contractor will assist on:

Reviewing for any changes on the processing of PII

Reviewing for any changes on the categorization on the system using the latest FIPS 199

Reviewing for any changes on the security control selection using the latest NIST SP 800-53. Reviewing for any changes on the implementation and documentation of the security and privacy controls

POA&M Management. The contractor will provide comprehensive support to ISSO in triaging and resolving vulnerabilities (Critical, High, Medium, Low) and managing Plan of Action and Milestones (POAMs) for IT security and compliance. This includes reviewing and mitigating vulnerabilities, POAM submissions, tracking POAM progress, coordinating with stakeholders to remediate vulnerabilities, updating vulnerabilities and POAM status reports, and ensuring compliance with established security policies and standards. The contractor will also assist in developing and implementing strategies to mitigate risks identified in POAMs, contributing to the overall security posture of the organization.

POA&M Remediation. The contractor shall remediate weaknesses identified during security testing as needed to ensure the system/application meets applicable security and privacy control requirements. The contractor shall document the resolution for each weakness in either Black Kite or ServiceNow that corresponds to either a vulnerability or POA&M and implement each resolution accordingly. In addition, the contractor shall remediate both vulnerabilities or POA&Ms in a timely manner to manage the risk associated with the in-scope security boundaries (SIS, Fusion, Compliance Applications) at an acceptable level of risk to enable the OCC to issue an initial ATO for the solution, as well as maintain its ongoing authorization thereafter.

Compliance Reviews and Audits. The contractor shall permit and support compliance reviews and audits under applicable laws to allow the OCC to meet legal and compliance obligations and shall implement processes that allow visibility into the privacy and security controls employed and their effectiveness. The contractor shall provide the OCC or authorized designated officials with information requested by auditors in a timely manner, consistent with the respective auditor's deadline, in support of security compliance reviews and various annual audits, e.g., FISMA, Financial Statement Audit, A-123, etc.

In addition, the contractor shall provide the OCC or authorized designated officials logical and physical access to the contractor's facilities, installations, technical capabilities, operations, records, and databases pertinent to this contract within seven (7) calendar days upon request for these purposes.

The OCC may decide to prioritize specific security controls in which the contractor must perform ISCM to include AC-2, AU-6, CA-5, RA-5, SI-2, and SI-3.

Continuous Monitoring Reports. The contractor shall submit monthly continuous monitoring reports to the OCC as directed in the "Security and Privacy Vendor Deliverables" section. At a minimum, the continuous monitoring reports shall detail vulnerabilities identified, secure configuration compliance findings and status, open POA&Ms; accepted risks status and rationale, and independent assessments planned/completed.

Annual 3PAO Security Assessment Report and Package Review. As mentioned in Section C. "Security and Privacy Authorization," under "FedRAMP Authorization to Operate," the contractor shall provide annual 3PAO Security Assessment Reports (SAR) reflecting the results of the assessment of a subset of controls completed by the 3PAO in accordance with the contractor's system ISCM Plan. The contractor shall provide these annual 3PAO SARs and updates to the Plan of Actions and Milestones, and System Security Plans and supporting documents, including the annual Contingency Plan (CP) Update and CP Test Report, to the OCC as directed in the "Security and Privacy Vendor Deliverables" section.

F. Data Protection

Data Encryption. Where encryption is required, as specified by the OCC, the contractor shall ensure that encryption is established and maintained for data at rest and in transit for the duration of the contract. The encryption employed shall be equivalent to those approved in Federal Information Processing Standards (FIPS) Publication 140-2 or 140-3.

Need to Know. Sensitive…