Appendix B of SOO - Non-Functional-Requirements-10012025.xlsx

XLSX spreadsheet 66 KB Posted Oct 2, 2025

Attached to: FDIC's File Management Categorization and Analysis Tool
Solicitation number: CORHQ-25-R-0409
Issued by: Federal Deposit Insurance Corporation

About this file

Written by GovTribe AI · Oct 2, 2025

The provided file is Appendix B of a Statement of Objectives (SOO), specifically a detailed non-functional requirements spreadsheet for a system or software implementation at the Federal Deposit Insurance Corporation (FDIC). The document comprehensively outlines 129 technical requirements across multiple domains including Availability/Reliability, Compliance, Data Management, Interoperability, Maintainability, Performance, Security, Software, Supportability, and Usability.

The requirements are meticulously structured with unique identifiers, mandatory status, descriptions, applicable standards, and designated responsible organizational units within the FDIC. Key focus areas include system performance, security protocols, accessibility standards (WCAG Level AA), cloud integration, zero trust architecture, data migration capabilities, role-based access controls, and compliance with federal regulations such as FISMA, NIST, and privacy standards. The requirements appear designed to ensure a robust, secure, and user-friendly technology solution that meets stringent federal government technology governance and implementation standards.

View the file

Other files

File	Type	Posted
CORHQ-25-R-0409-Amendment 0002.pdf	PDF	Oct 16, 2025
FDIC CORHQ-25-R-0409_QA Spreadsheet_10-3-25 - UPDATED.xlsx	XLSX spreadsheet	Oct 3, 2025
CORHQ-25-R-0409-Amendment 0001.pdf	PDF	Oct 2, 2025
Price Schedule - revised 10-2-25.xlsx	XLSX spreadsheet	Oct 2, 2025
QA Spreadsheet.xlsx	XLSX spreadsheet	Sep 12, 2025
Pre-Award SCRM Info - Example.xlsx	XLSX spreadsheet	Sep 12, 2025
CORHQ-25-R-0409.pdf	PDF	Sep 12, 2025
Price Schedule.xlsx	XLSX spreadsheet	Sep 12, 2025

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

V2.0 Requirements

Requirements Type

Description

Not Applicable

Mandatory

Assumptions / Constraints

Enabling Organizations

Example

Standards / Publications

Applicable to SaaS

Applicable to Custom Build

Applicable to COTS Product

Comments

ARR-1

Availability, Reliability, Recoverability

Systems shall be able to have their state (data / metadata / configuration) backed up and restored.

IOSB/Infrastructure Operation Management Section (IOMS)

SQL Database Backup, Azure Database Backup, etc.

ARR-2

Availability, Reliability, Recoverability

Systems shall be available to all users at all times except during scheduled downtimes.

Scheduled downtimes should not exceed 2 hours and should not occur during normal business hours. (Monday - Friday between the hours of 6 am to 9pm Eastern Standard Time (EST)).

Application Platforms & Delivery Branch (APDB)

ARR-3

Availability, Reliability, Recoverability

Systems shall provide a total system uptime percentage for the end user based on the FDIC's defined "Acceptable Quality Levels", except during scheduled maintenance.

Application Platforms & Delivery Branch (APDB)

Gold - 99.5%

Silver - 98%

Bronze - 95%		Y	Y	N
	ARR-4	Availability, Reliability, Recoverability	Systems shall provide high availability for the database as up-time based on the FDIC's defined "Acceptable Quality Levels", except during scheduled maintenance.		Y	IOSB/Database, Tools and Content Unit (DTCU)	Gold - 99.5%

Silver - 98%

Bronze - 95%		N	Y	N
	ARR-5	Availability, Reliability, Recoverability	Systems shall provide end-to-end visibility of its availability and performance so it can be measured against pre-defined service level targets.		Y		Application Platforms & Delivery Branch (APDB)	System provides a "/health API endpoint" that indicates the status / health of the system	Y	Y	N
	ARR-6	Availability, Reliability, Recoverability	Systems shall be implemented and maintained for continued availability and performance, with recoverability, geographic redundancy, and maintainability incorporated at the time of design.		Y		Application Platforms & Delivery Branch (APDB)		Y	Y	N
	ARR-7	Availability, Reliability, Recoverability	Systems shall provide an interface to allow for data protection (backups) aligned with the FDIC's backup requirements.		Y	Assumes the FDIC has defined the following: Maximum tolerable Downtime (MTD), Recovery Point Objective (RPO) and Recovery Time Objective (RTO).	Application Platforms & Delivery Branch (APDB)		Y	Y	N
	ARR-8	Availability, Reliability, Recoverability	Systems shall ensure that their Disaster Recovery approach is consistent with defined thresholds established by the FDIC's Maximum tolerable Downtime (MTD), Recovery Point Objective (RPO) and Recovery Time Objective (RTO).		Y		IOSB/Infrastructure Operation Management Section (IOMS)		Y	Y	N
	ARR-9	Availability, Reliability, Recoverability	Systems shall adhere to Disaster Recovery (DR) tests/exercises in accordance with FDIC's organizationally-defined frequency (at least annually).	Not Applicable	Y		IOSB/Infrastructure Operation Management Section (IOMS)		Y	Y	N
	ARR-10	Availability, Reliability, Recoverability	Systems' architecture shall be compatible with the FDIC's existing Disaster Recovery environment if hosted in the FDIC data center.		Y		IOSB/ Infrastructure Management Services Unit (IMSU)		N	Y	N
	ARR-11	Availability, Reliability, Recoverability	Systems shall be successfully restored, recovered, and tested in the FDIC's Disaster Recovery environment prior to implementation in a production environment if hosted in FDIC data center.		Y		IOSB/ Infrastructure Management Services Unit (IMSU)		N	Y	N
	ARR-12	Availability, Reliability, Recoverability	Systems shall be successfully restored, recovered, and tested in a cloud service provider's environments prior to implementation in a production environment.	Not Applicable	Y		IOSB/Infrastructure Operation Management Section (IOMS)		Y	Y	N
	ARR-13	Availability, Reliability, Recoverability	Systems shall be designed for high availability and has been built with failover support at each of the tiers.		_	May be handled at the platform level or SLA dependent	ESB/Architecture and Design Section (ADS)		N	Y	N
	ARR-14	Availability, Reliability, Recoverability	Systems shall be resilient against Denial of Service (DoS) attacks that interrupt operations and impact authorized users from accessing the system.		Y		IOSB/Network Services (NSS)		Y	N	N
	ARR-15	Availability, Reliability, Recoverability	Systems with client-side components shall been built to handle unreliable network connections.		Y	Dependent on application SLA	Application Platforms & Delivery Branch (APDB)		Y	Y	Y
	ARR-16	Availability, Reliability, Recoverability	Systems shall be designed so runtime upgrades i.e., security patches and application upgrades can be performed while the system is available to the user when possible.		_	Dependent on application SLA	Application Platforms & Delivery Branch (APDB)		N	Y	Y
	ARR-17	Availability, Reliability, Recoverability	Systems shall be recoverable and automatically rebuilt/re-deployed.		Y		Application Platforms & Delivery Branch (APDB)		N	Y	Y
	ARR-18	Availability, Reliability, Recoverability	Systems shall be built for component failure and have the ability to remain operational over time.		_	May be handled at the platform level or SLA dependent	Application Platforms & Delivery Branch (APDB)		N	Y	Y
	ARR-19	Availability, Reliability, Recoverability	Systems with server based components shall automatically detect failures and use load balancers to move connections onto surviving servers.		Y		Application Platforms & Delivery Branch (APDB)		N	Y	Y
	ARR-20	Availability, Reliability, Recoverability	Systems with server based components shall use asynchronous queuing so that requests can be stored when the system is unavailable and replayed when it is online.		N		Application Platforms & Delivery Branch (APDB)		N	Y	Y
	CMP-1	Compliance	Systems shall maintain release currency of software (as directed by the FDIC).		Y	Typically versions no older than two versions behind the latest publicly available production (non-beta) release of the software are supported / acceptable.	Application Platforms & Delivery Branch (APDB)		N	Y	Y
	CMP-2	Compliance	System shall comply with all records management laws, regulations, and policies applicable to the FDIC.		Y	As described in Directive 1210.01 - Records and Information Program	Division of Administration (DOA)		Y	Y	Y
	CMP-3	Compliance	Systems shall automatically audit account creation, modification, enabling, disabling, removal actions, and notifications for organization-defined personnel or roles.		Y		IOSB/Infrastructure Operation Management Section (IOMS)		Y	Y	Y
	CMP-4	Compliance	Systems shall generate audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event.		Y		Application Platforms & Delivery Branch (APDB)		Y	Y	Y
	CMP-5	Compliance	Systems shall back up audit records at least daily onto a physically different systems/component than the systems/component being audited.		Y	Cloud: Audit information should be streamed in real time to a log / audit aggregation framework.

On-prem: Audit information should be externalized to the server hosting the application.	Infrastructure and Operations Services Branch (IOSB)			Y	Y	N
	CMP-6	Compliance	Systems shall support FDIC's log and security data management/audit capability that utilizes FDIC's centralized log management infrastructure.		Y	May be handled at the platform level	Application Platforms & Delivery Branch (APDB)	Y	Y	Y
	CMP-7	Compliance	Systems shall provide audit record generation capability for defined auditable events.		Y		Application Platforms & Delivery Branch (APDB)	Y	Y	Y
	CMP-8	Compliance	Systems shall track all changes to roles and permissions.		Y		Application Platforms & Delivery Branch (APDB)	Y	Y	Y
	CMP-9	Compliance	Systems shall track all activity related events.		Y	The following but not limited to, to the following events:

- Systems access events

- Document events

- Meta‐data events

- Systems configuration setting events

- Group management events

- Workflow events

- Record create/update/delete events

Application Platforms & Delivery Branch (APDB)

CMP-10

Compliance

Systems shall enable all auditable data to be available for a configurable amount of time.

Externalizing auditable data to enterprise logging is sufficient

Application Platforms & Delivery Branch (APDB)

CMP-11

Compliance

Systems shall provide the capability or integrate with an external capability to track information in audit records for audit events (e.g. event type, source, or subject).

Application Platforms & Delivery Branch (APDB)

CMP-12

Compliance

Systems shall process or integrate with an external capability to audit records of interest, automatically based upon selectable event criteria.

Mandatory for systems that manage FDIC records

Application Platforms & Delivery Branch (APDB)

CMP-13

Compliance

Systems shall provide the capability or integrate with an external capability to filter audit records.

Application Platforms & Delivery Branch (APDB)

CMP-14

Compliance

Systems shall notify or integrate with an external capability to notify appropriate organization officials in the event of an audit failure of interest.

Application Platforms & Delivery Branch (APDB)

CMP-15

Compliance

Systems shall provide the capability to review audit logs for after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements.

OCISO/Enterprise Security Operations Section (ESOS)

CMP-16

Compliance

Systems shall track the create, update, and delete events related to user accounts, user roles, groups, and systems privileges.

Normally handled with integration with ARCS

IOSB/Infrastructure Operation Management Section (IOMS)

CMP-17

Compliance

Systems shall log account creation, modification, disabling, and termination actions and to notify appropriate individuals, as required.

Normally handled with integration with ARCS

IOSB/Infrastructure Operation Management Section (IOMS)

CMP-18

Compliance

Systems shall log details of database audit events including user, user role, date and time, category, event type, event ID, source, and target object.

IOSB/Document and Database Services Unit (DDASU)

CMP-19

Compliance

Systems shall have the capability to log when an object permission, such as SELECT, has been used.

IOSB/Document and Database Services Unit (DDASU)

CMP-20

Compliance

Systems shall log when a GRANT, DENY or REVOKE event has occurred for user or for a schema objects in the database.

IOSB/Document and Database Services Unit (DDASU)

CMP-21

Compliance

Systems shall log when shutdown, start, and pause activities for system services have occurred.

IOSB/Infrastructure Operation Management Section (IOMS)

CMP-22

Compliance

Systems shall log when diagnostically detected faults and system errors have occurred.

IOSB/Infrastructure Operation Management Section (IOMS)

CMP-23

Compliance

Systems shall log system configuration changes.

IOSB/Infrastructure Operation Management Section (IOMS)

CMP-24

Compliance

Systems shall log normal system start and shutdown.

May be handled at the platform level

IOSB/Infrastructure Operation Management Section (IOMS)

CMP-25

Compliance

Systems shall alert designated system personnel in the event of an audit processing failure.

IOSB/Infrastructure Operation Management Section (IOMS)

CMP-26

Compliance

Systems shall log/track records containing PII that are exported from the application.

OCISO/Privacy Staff

OMB Circular A-130

CMP-27

Compliance

Systems shall comply with all aspects of the Federal Information Security Modernization Act (FISMA), including the specified National Institute for Standards in Technology (NIST) Risk Management Framework (RMF).

FISMA Moderate

OCISO/Cyber Risk Management Section (CRMS)

FISMA, NIST, RMF

CMP-28

Compliance

Systems shall adhere to requirements and expectations of the Federal Risk & Authorization Management Program (FedRAMP) for Cloud Services, as set forth in the FedRAMP Agency Authorization Playbook (AAP), ensuring that any gaps between the Cloud Security Provider's (CSP) obligations under FedRAMP and the remainder of the FDIC's own tailored security authorization requirements are documented in the System Security Plan (SSP).

FedRAMP Moderate

OCISO/Cyber Risk Management Section (CRMS)

FedRAMP AAP

CMP-29

Compliance

Systems shall be approved by FDIC’s Authority to Operate (ATO) process before being allowed into production.

OCISO/Cyber Risk Management Section (CRMS)

CMP-30

Compliance

Systems shall comply with all relevant aspects of the Cybersecurity Information Sharing Act (CISA), by appropriately sharing relevant security-related information.

OCISO/Cyber Risk Management Section (CRMS)

CISA

CMP-31

Compliance

Systems shall adhere to FDIC's Information Security Continuous Monitoring Program.

May be handled at the platform level

OCISO/Enterprise Security Operations Section (ESOS)

CMP-32

Compliance

Systems shall provide a system use warning screen(s) that makes it clear to the user that the system contains Controlled Unclassified Information (CUI) for which the user is responsible to safeguard in accordance with FAR Title 32 CFR 2002 and agency policy, a description of authorized uses, privacy accommodations and notifications.

Application Platforms & Delivery Branch (APDB)

FAR Title 32 CFR 2002

CMP-33

Compliance

Systems shall support logging of search queries of sensitive information for auditability.

OCISO/Privacy Staff

CMP-34

Compliance

Systems shall align with the FDIC's Target State Architecture and adopted patterns.

ESB/Architecture and Design Section (ADS)

CMP-35

Compliance

Systems shall not introduce duplicate technology already in the FDIC's environments.

Unless approved by SEATAB

ESB/Architecture and Design Section (ADS)

CMP-36

Compliance

Systems shall prevent the alienation or unauthorized destruction of FDIC information, including all forms of mutilation. Information may not be destroyed except for in accordance with the provisions of the FDIC Records Retention Schedule (RRS) and with the written concurrence of the FDIC.

Division of Administration (DOA)

CMP-37

Compliance

Systems shall maintain all associated metadata and be accompanied by sufficient technical documentation to permit understanding and use of the information.

Division of Administration (DOA)

CMP-38

Compliance

Systems shall invoke a suspension of any disposition actions that a record may otherwise be eligible for due to legal or other preservation hold. Systems shall resume disposition activities upon release of hold.

Division of Administration (DOA)

CMP-39

Compliance

Systems shall ensure that any export of records includes all associated metadata and audit trail data.

Division of Administration (DOA)

CMP-40

Compliance

Systems shall provide the capability to search records based on the appropriate user access.

Division of Administration (DOA)

CMP-41

Compliance

Systems shall create and manage records that are authentic, reliable, complete, unaltered, and usable.

Division of Administration (DOA)

ISO 15489

CMP-42

Compliance

Systems shall pass quality gates as determined by the FDIC’s code quality standards and static analysis capabilities / frameworks.

FDIC’s code quality and static analysis capabilities / frameworks: FDIC’s SonarQube and SonarQube configuration

Application Platforms & Delivery Branch (APDB)

CMP-43

Compliance

Systems that interface with AI technologies shall adhere to FDIC AI governance policy, standards and guidelines

Additional document to come. Use existing Fed wide guidance

DAT-1

Data

Systems shall manage all state transitions as part of a transaction.

ESB/Architecture and Design Section (ADS)

X/Open XA standard

DAT-2

Data

Systems shall leverage enterprise data from existing applications through defined and supported interfaces.

Application Platforms & Delivery Branch (APDB)

FDIC Enterprise wide Data Model https://fdicnet.fdic.gov/content/dit/home/itgovernance/cdo/cdm.html

REST / GraphQL

DAT-3

Data

Systems shall implement unique IDs assigned to individual database records - Identify and capture Natural primary key that can uniquely determine the data.

Systems shall implement unique IDs assigned to individual database records, and if a system generated unique ID is used, create and index a business key that uniquely identifies the record

Chief Data Officer Staff (CDOS)

DAT-4

Data

Systems shall have the capability to capture audit information for individual database records.

Chief Data Officer Staff (CDOS)

DAT-5

Data

Systems shall provide all data change tracking timestamps (current and historical) based on the system server time.

IOSB/Document and Database Services Unit (DDASU)

DAT-6

Data

Systems shall not allow users direct transactional / operational database access, all database access should be via systems components, API, or reporting databases.

ESB/Architecture and Design Section (ADS)

DAT-7

Data

Systems shall provide the capability to archive information.

Chief Data Officer Staff (CDOS)

DAT-8

Data

Systems shall provide the capability to tag documents and data with metadata to clearly identify digital content containing sensitive information (e.g. PII) using standard tagging and nomenclature.

OCISO/Privacy Staff

For example: https://fdicnet.fdic.gov/content/dam/dit/services/datamanagement/data-protection-program/fdic-document-labeling-guide.pdf

OMB Circular A-130

DAT-9

Data

Systems shall secure content according to meta‐data values populated for the documents and data.

Chief Data Officer Staff (CDOS)

DAT-10

Data

Systems shall capture file / document metadata.

The following but not limited to:

- Name

- Version count

- Source of document

- Contains sensitive information or PII

- Family of Data

- Retention based on applicable LRPGs

Chief Data Officer Staff (CDOS)

OMB Circular A-130

DAT-11

Data

FDIC systems shall serve as a source of trusted and contextual information that can be used to support business functions and decision-making. They shall be capable of serving as instruments of accountability by providing accurate and reliable evidence of actions and transactions.

Application Platforms & Delivery Branch (APDB)

DAT-12

Data

Systems shall have the ability to track all changes to non-relational data.

Chief Data Officer Staff (CDOS)

DAT-13

Data

Systems shall track the user (non-system account user) and time when information was created, modified or deleted.

Chief Data Officer Staff (CDOS)

DAT-14

Data

Systems shall track the user (or system account) and time when information was viewed.

Chief Data Officer Staff (CDOS)

Data

Systems shall track all changes made to all data and document.

Chief Data Officer Staff (CDOS)

DAT-16

Data

Systems shall allow records containing Personally Identifiable Information (PII) and sensitive information to be easily identifiable (e.g. applying tag/indicator to PII) for access and reporting.

OCISO/Privacy Staff

OMB Circular A-130

DAT-17

Data

Systems shall provide the ability to process multiple reports and queries in parallel.

APDB/Business Intelligence Services Section (BISS)

DAT-18

Data

Systems shall have the capability to generate reports in multiple formats.

Systems that have a reporting capability

APDB/Business Intelligence Services Section (BISS)

e.g. excel, pdf, csv, txt

https://www.w3.org/TR/xml/

CSV, XML, JSON

DAT-19

Data

Systems shall provide the capability to export data to at least one of the FDIC's preferred formats.

This requirement is aimed at reporting capabilities.

FDIC preferred formats:

- Excel

- CSV

- XML

- JSON

APDB/Business Intelligence Services Section (BISS)

https://www.w3.org/TR/xml/

CSV, XML, JSON

DAT-20

Data

Systems shall provide the capability to integrate with FDIC's existing reporting/analytic tools.

Systems that have a reporting capability

APDB/Business Intelligence Services Section (BISS)

DAT-21

Data

Systems shall maintain the association between underlying structured data and external unstructured data.

Application Platforms & Delivery Branch (APDB)

Maintain the mapping of the location of unstructured data in the system

DAT-22

Data

System shall provide the capability to automatically keep indexes optimized used in search operations.

Application Platforms & Delivery Branch (APDB)

DAT-23

Data

Systems shall encapsulate all transactional / operational data access functionality.

ESB/Architecture and Design Section (ADS)

DAT-24

Data

Systems that are consumers of a data layer shall interact through encapsulation mechanisms to avoid creating tightly coupled dependencies and data variability.

ESB/Architecture and Design Section (ADS)

DAT-25

Data

Systems shall utilize data selectors like choice and dropdown fields, only using freeform entry when necessary - utilize constraints in database design

Chief Data Officer Staff (CDOS)

DAT-26

Data

Systems shall provide reference data sources as configurable items. Use reference tables to drive data

Chief Data Officer Staff (CDOS)

DAT-27

Data

System shall follow FDIC confidentiality and security for test data policy over masked data.

DM-1

Data Migration

Systems shall provide the ability to export all data in a neutral data format that can be readily ingested.

This requirement is aimed at data exit / migration strategies.

Chief Data Officer Staff (CDOS)

https://www.w3.org/TR/xml/

CSV, XML, JSON

DM-2

Data Migration

Systems shall provide the capability to migrate structured data and unstructured data.

This functionality would be handled by data engineering platform capability.

Chief Data Officer Staff (CDOS)

DM-3

Data Migration

Systems shall provide the capability to import and export documents and data via secure channels and/or standard protocols.

Application Platforms & Delivery Branch (APDB)

DM-4

Data Migration

Systems shall provide the capability to migrate records from existing FDIC systems into the new systems. During records migration, all records and associated metadata in the originating systems must be retained until the migration is complete and the destination systems has been deemed reliable and secure.

Not Applicable

Chief Data Officer Staff (CDOS)

DM-5

Data Migration

Systems shall preserve all metadata during a data migration and ensure that the metadata accompanies the transfer.

Not Applicable

Chief Data Officer Staff (CDOS)

DM-6

Data Migration

Systems shall interface with FDIC tools to exchange data and documents to/from institutions and third parties.

Not Applicable

Application Platforms & Delivery Branch (APDB)

API

APIs

DM-7

Data Migration

Systems shall provide the capability to export data into multiple formats.

Not Applicable

Chief Data Officer Staff (CDOS)

CSV, XML, JSON

INT-1

Interoperability

Systems shall be capable of operating in an IPv4 / IPv6 environment and an IPv6 only environment.

Not Applicable

IOSB/Network Services (NSS)

IPv6

INT-2

Interoperability

Systems shall function through the current FDIC network infrastructure.

IOSB/ Network Services Unit (NSU)

INT-3

Interoperability

Systems shall operate when connected through FDIC VPN.

IOSB/Network Services (NSS)

INT-4

Interoperability

Systems shall operate and be accessible via all FDIC devices (workstations, mobile devices, etc.).

IOSB/End User Computing Section (EUCS)

INT-5

Interoperability

Systems shall operate when connected through FDIC LAN/WAN, including FDIC-provided WiFi.

IOSB/Network Services (NSS)

INT-6

Interoperability

Systems shall operate when the client is in VPN split tunneling mode.

IOSB/Network Services (NSS)

INT-7

Interoperability

Systems shall support operating in the FDIC's Zero Trust environment.

To the extent of the FDIC's Zero Trust Architecture specification.

OCISO/Cyber Assurance Services Section (CASS)

INT-8

Interoperability

Systems shall utilize a cloud integration service to integrate systems.

ESB/Architecture and Design Section (ADS)

INT-9

Interoperability

Systems shall provide access to its data in a managed way (e.g. via data pipelines, event mechanisms, etc.) in order to integrate with other solutions.

ESB/Architecture and Design Section (ADS)

INT-10

Interoperability

Systems shall leverage the FDIC’s enterprise application integration service to integrate on-premise components of systems.

ESB/Architecture and Design Section (ADS)

INT-11

Interoperability

Systems shall comply with interoperability industry standards unless there is a compelling reason to implement a non-standard solution.

ESB/Architecture and Design Section (ADS)

REST based services, XML, JSON, gRPC, CloudEvents

INT-12

Interoperability

Systems APIs shall be secure and support security mechanisms to control access.

Not Applicable

ESB/Architecture and Design Section (ADS)

INT-13

Interoperability

Systems shall ensure that it's APIs can be published so they are reusable.

Not Applicable

ESB/Architecture and Design Section (ADS)

INT-14

Interoperability

Systems shall ensure that it's APIs support a scalable environment.

Not Applicable

ESB/Architecture and Design Section (ADS)

INT-15

Interoperability

Systems shall support API versioning.

Application Platforms & Delivery Branch (APDB)

INT-16

Interoperability

Systems shall support API monitoring.

Application Platforms & Delivery Branch (APDB)

INT-17

Interoperability

Systems shall support API usage analytics.

Application Platforms & Delivery Branch (APDB)

INT-18

Interoperability

Systems shall ensure uniformity in multiple API implementations and versions.

Not Applicable

Application Platforms & Delivery Branch (APDB)

INT-19

Interoperability

Systems shall support publishing APIs for internal and external customers.

Not Applicable

Application Platforms & Delivery Branch (APDB)

INT-20

Interoperability

Systems shall reuse the existing available APIs or services.

Not Applicable

ESB/Architecture and Design Section (ADS)

INT-21

Interoperability

Systems shall support integration into an Enterprise Service Integration Platform (iPaaS - Integration Platform as a Service) or message broker.

Not Applicable

ESB/Architecture and Design Section (ADS)

An Enterprise Service Integration Platform integrates different applications and services (i.e. MuleSoft, Azure Integration Services).

INT-22

Interoperability

Systems shall support capabilities of event/message-driven integration.

Not Applicable

ESB/Architecture and Design Section (ADS)

INT-23

Interoperability

Systems shall support message routing, queuing, and guarantee delivery.

Not Applicable

Normally handled by integration with a message broker

ESB/Architecture and Design Section (ADS)

INT-24

Interoperability

Systems shall support Business Process Modeling Notation (BPMN) 2.0 when BPMN is used.

Not Applicable

ESB/Architecture and Design Section (ADS)

BPMN 2.0

INT-25

Interoperability

Systems shall support output of audit logs in a format that is ingestible by the FDIC's logging/auditing framework.

Splunk

OCISO/Enterprise Security Operations Section (ESOS)

INT-26

Interoperability

Systems shall use an FDIC approved industry-recognized virtualization platform (i.e. VMWare & Azure) to help ensure interoperability.

IOSB/ Infrastructure Management Services Unit (IMSU)

INT-27

Interoperability

Systems shall interface with MS Office 365 for the purposes of email notifications.

Application Platforms & Delivery Branch (APDB)

INT-28

Interoperability

Systems shall support integration (searching of data) with data visualization tools (e.g. Tableau).

APDB/Business Intelligence Services Section (BISS)

INT-29

Interoperability

Systems shall maintain database implementation Independance whenever possible.

ESB/Architecture and Design Section (ADS)

INT-30

Interoperability

Systems shall use well-structured XML or JSON using a registered schema for inter-system communication.

ESB/Architecture and Design Section (ADS)

https://www.w3.org/TR/xml/

XML, JSON

INT-31

Interoperability

Systems shall use JavaScript Object Notation (JSON) for intra-system communication between a web browser and a service.

ESB/Architecture and Design Section (ADS)

JSON

INT-32

Interoperability

Systems shall expose and consume messages that are based on XML and other industry standards.

ESB/Architecture and Design Section (ADS)

https://www.w3.org/TR/xml/

XML

INT-33

Interoperability

Systems shall leverage JavaScript Object Notation (JSON) or Extensible Markup Language (XML) for representation of data and corresponding schema definition for validation of data structure.

Application Platforms & Delivery Branch (APDB)

https://www.w3.org/TR/xml/

XML, JSON

INT-34

Interoperability

Systems shall interact through a standardized interface only and there will be no awareness of what is behind the interface (clean boundaries).

ESB/Architecture and Design Section (ADS)

INT-35

Interoperability

Systems shall avoid reliance on other system's internal APIs or databases. This will save time from troubleshooting “unannounced” changes and each side of the system can change at will.

ESB/Architecture and Design Section (ADS)

INT-36

Interoperability

Systems shall design components to be cohesive and have low coupling in order to maximize the flexibility of the design and to facilitate replacement.

ESB/Architecture and Design Section (ADS)

INT-37

Interoperability

Systems shall design interfaces to avoid batch processing and leverage events to facilitate real time processing.

ESB/Architecture and Design Section (ADS)

INT-38

Interoperability

Systems shall use a service layer to implement service interfaces and expose application contracts.

ESB/Architecture and Design Section (ADS)

INT-39

Interoperability

Systems' service operations (external APIs) shall be coarse grained and focused on application operations and not component-scoped operations.

ESB/Architecture and Design Section (ADS)

INT-40

Interoperability

Systems' service interfaces shall not be affected by changes to the business logic.

ESB/Architecture and Design Section (ADS)

INT-41

Interoperability

Systems shall leverage the CloudEvents standard 1.0+ for event based architectures.

The CloudEvents standard is preferred.

ESB/Architecture and Design Section (ADS)

CloudEvents

standard 1.0+

INT-42

Interoperability

Systems shall use one or more of the following service styles for interoperability: Representational State Transfer (REST), GraphQL, and OData.

ESB/Architecture and Design Section (ADS)

REST, SOAP, GraphQL, Odata

INT-43

Interoperability

Systems shall minimize decoupling through API first approaches.

ESB/Architecture and Design Section (ADS)

INT-44

Interoperability

Systems shall be designed to promote the creation of reusable service, allowing components to be easily shared and integrated across different modules and applications.

ESB/Architecture and Design Section (ADS)

INT-45

Interoperability

Systems shall adhere to FDIC Application Programing Interface (API) Development Standard, ensuring consistent design, documentation, and implementation practices for ease of integration across systems. Please refer to https://fdicnet.fdic.gov/content/dam/dit/itgovernance/enterprisearchitecture/content/documents/Application%20Programming%20Interface%20(API)%20Development%20Standard_Final.pdf.

ESB/Architecture and Design Section (ADS)

MNT-1

Maintainability

System shall use common FDIC enterprise platforms, services and APIs. Please refer to https://fdicnet.fdic.gov/content/dam/dit/itgovernance/enterprisearchitecture/documents/Enterprise-Service-Registry.xlsx for a list of reusable services.

ESB/Architecture and Design Section (ADS)

MNT-2

Maintainability

Systems shall consist of re-usable, loosely coupled modular components.

Application Platforms & Delivery Branch (APDB)

MNT-3

Maintainability

Systems shall support configurable business logic that can be managed by authorized users without programming (in areas where business logic changes regularly e.g. quarterly, yearly, etc.).

Application Platforms & Delivery Branch (APDB)

MNT-4

Maintainability

Systems shall be developed using a Continuous Integration and Continuous Delivery (CI/CD) pipeline that fully adheres to the principle of building-in security at each step, which requires a full suite of relevant tools/capabilities such as code scanning, site security scanning, automated code vulnerability detection, log management & analysis, open source vulnerability management, secure release orchestration etc.

APDB/Delivery Automation and User Experience Section (DAUXS)

MNT-5

Maintainability

Systems shall adhere to an established Configuration Management (CM) plan.

APDB/Delivery Automation and User Experience Section (DAUXS)

MNT-6

Maintainability

Systems shall provide a management command line interface (CLI) that shall expose all product features to allow provisioning, decommissioning, and configuration of the system's resources.

APDB/Delivery Automation and User Experience Section (DAUXS)

MNT-7

Maintainability

Systems shall leverage designs that use a Service-oriented and event-driven architecture (SOA and EDA) to facilitate the development of solutions as modular business services that can be easily integrated and reused to build new capabilities.

ESB/Architecture and Design Section (ADS)

MNT-8

Maintainability

Systems shall use service interfaces residing in a service layer to expose the functionality of components.

ESB/Architecture and Design Section (ADS)

MNT-9

Maintainability

Systems shall implement services that provide / consume platform agnostic data types and structures.

ESB/Architecture and Design Section (ADS)

MNT-10

Maintainability

Systems shall use existing services or components instead of creating new ones. If additional functionality is needed, teams should enhance the existing service and make it available for other solutions to use.

ESB/Architecture and Design Section (ADS)

MNT-11

Maintainability

Systems shall expose their services in a catalog.

ESB/Architecture and Design Section (ADS)

MNT-12

Maintainability

Systems shall register the use of any existing services.

ESB/Architecture and Design Section (ADS)

MNT-13

Maintainability

Systems shall promote standard information exchanges based on FDIC canonical message formats derived from the business object models of systems. This will allow information to be transmitted quickly and effortlessly among business layer components, SOA service interfaces, and business events.

Chief Data Officer Staff (CDOS)

MNT-14

Maintainability

Systems shall isolate technology to individual layers in order to reduce risk and minimize the overall impact of a technology upgrade.

ESB/Architecture and Design Section (ADS)

MNT-15

Maintainability

Systems shall be built so that changes in one layer do not impact other layers.

ESB/Architecture and Design Section (ADS)

MNT-16

Maintainability

Systems shall be built so that it can quickly adapt to changing business requirements and technology advancements.

ESB/Architecture and Design Section (ADS)

MNT-17

Maintainability

Systems shall be documented so that at a minimum the overall structure of the system, components, and services interactions are described and explained.

ESB/Architecture and Design Section (ADS)

MNT-18

Maintainability

System shall use consistent terminologies and notations for data entities.

Chief Data Officer Staff (CDOS)

MNT-19

Maintainability

Systems shall use consistent terminologies and notations for business functions, components, and interfaces.

ESB/Architecture and Design Section (ADS)

MNT-20

Maintainability

Systems shall be rebuildable using FDIC approved DevOps pipeline capabilities.

APDB/Delivery Automation and User Experience Section (DAUXS)

MNT-21

Maintainability

Systems shall have associated meta-data that specify system version.

APDB/Delivery Automation and User Experience Section (DAUXS)

MNT-22

Maintainability

Systems shall have system builds that are not dependent on the target lifecycle / promotional environments (i.e. Dev, QA, Prod). Only deployment plans are unique for different target environments. No configuration file changes will be made during deployment.

APDB/Delivery Automation and User Experience Section (DAUXS)

MNT-23

Maintainability

Systems shall have builds that automatically execute vulnerability scans and report results.

APDB/Delivery Automation and User Experience Section (DAUXS)

MNT-24

Maintainability

Systems shall have builds that automatically execute unit test scripts and report the percentage passed or failed.

APDB/Delivery Automation and User Experience Section (DAUXS)

MNT-25

Maintainability

Systems shall create configuration management baselines at critical points throughout the project. At least one at the end of every iteration.

APDB/Delivery Automation and User Experience Section (DAUXS)

MNT-26

Maintainability

Systems shall be modular, divided into distinct features with no overlap in functionality between features, to support testing.

ESB/Architecture and Design Section (ADS)

MNT-27

Maintainability

System components shall be designed to have high cohesion and low coupling to allow testability of components in isolation from the rest of system.

ESB/Architecture and Design Section (ADS)

MNT-28

Maintainability

Systems shall create integration testing for all developed subsystems.

APDB/Delivery Automation and User Experience Section (DAUXS)

MNT-29

Maintainability

Unit tests shall be created for all developed components.

Application Platforms & Delivery Branch (APDB)

MNT-30

Maintainability

Automated unit and integration testing shall be performed for all components within the build pipeline.

Application Platforms & Delivery Branch (APDB)

MNT-31

Maintainability

Systems shall have a solution architecture that reflects a layered and component-based architecture style.

ESB/Architecture and Design Section (ADS)

MNT-32

Maintainability

Systems with a presentation layer shall be organized so that it is responsible for displaying the user interface and manage user interaction. The presentation layer should not contain business logic or data access logic.

ESB/Architecture and Design Section (ADS)

MNT-33

Maintainability

Systems with presentation layer (client vs server side) validations shall perform validation routines with minimal server communication.

Application Platforms & Delivery Branch (APDB)

MNT-34

Maintainability

Systems shall perform business level validations at the business layer.

It may be appropriate to perform certain validations at both the presentation layer and the business layer for performance reasons.

Application Platforms & Delivery Branch (APDB)

MNT-35

Maintainability

Systems shall use abstractions to implement loosely coupled interfaces between layers.

ESB/Architecture and Design Section (ADS)

MNT-36

Maintainability

Systems shall avoid circular dependencies so that components in one layer only know about the layer below and not the layer above.

ESB/Architecture and Design Section (ADS)

MNT-37

Maintainability

The system shall align with the DIT Roadmap, adhering to strategic milestones and target technology initiatives, to ensure long-term sustainability in line with the FDIC strategic objectives. Please refer to https://roadmap.fdic.gov/roadmap.

tc={A2A8C185-D48C-4415-BBFE-1E390596E6FE}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

too subjective to validate Reply:

make sure we are not exposing sensitive information.		Y		ESB/Architecture and Design Section (ADS)			N
	PRF-1	Performance	Systems shall provide the capability to monitor system performance.		Y	Provide the capability to monitor system performance for the following:

- application start up times

- load times

- user response times

- job/workflow execution times

- report execution times

- peak usage times

- user volume	Application Platforms & Delivery Branch (APDB)			Y
	PRF-2	Performance	Systems shall support horizontal and vertical scalability to support future increases in user and data loads.		Y		Application Platforms & Delivery Branch (APDB)			N
	PRF-3	Performance	Systems shall track performance and usage of all features (screens/modules/components/reporting) implemented.		N		Application Platforms & Delivery Branch (APDB)			N
	PRF-4	Performance	Systems shall measure the end-to-end/roundtrip performance at the application level from the user's perspective.		Y	OpenTelemetry Standard	Application Platforms & Delivery Branch (APDB)			N
	PRF-5	Performance	Systems shall track each point in time that a request/response hits each layer of the application/platform.		N	OpenTelemetry Standard	Application Platforms & Delivery Branch (APDB)			N
	PRF-6	Performance	Systems shall provide the capability to report trends in performance metrics.		N	OpenTelemetry Standard	Application Platforms & Delivery Branch (APDB)	e.g. time spent on authentication, application server connections, and backend processing.		N
	PRF-7	Performance	Systems shall support asynchronous loading of webpages when displaying a large amount of data on a page.		Y		Application Platforms & Delivery Branch (APDB)	i.e. lazy loading, infinite scrolling		N
	PRF-8	Performance	Systems shall finish rendering/displaying a screen after navigation to a new page within 2 seconds on networks with 25ms or less of latency, increasing proportionally as network latency increases.		Y		Application Platforms & Delivery Branch (APDB)			Y
	PRF-9	Performance	Systems shall ensure overall system performance degradation does not occur while executing/retrieving reports and queries.		Y		APDB/Business Intelligence Services Section (BISS)			Y
	PRF-10	Performance	Systems shall be designed to support documented Key Performance Indicators (KPI) with appropriate Service Level Agreement (SLA).		Y		Application Platforms & Delivery Branch (APDB)	e.g. load times, navigation times, etc.		Y
	PRF-11	Performance	Systems shall produce predictable outcomes under predefined usage scenarios.		Y		Application Platforms & Delivery Branch (APDB)	Systems should have both positive and negative test cases defined with predefined results.		N
	PRF-12	Performance	Systems shall use coarse-grained interfaces when communication must cross process or tier boundaries.		Y		ESB/Architecture and Design Section (ADS)			N
	PRF-13	Performance	Systems shall use a data paging strategy when querying for information and uses a default page size that is appropriate for the amount of data displayed. User should have the ability to change the default page size, but is constrained to a maximum value that will not impact performance.		Y		Application Platforms & Delivery Branch (APDB)			Y
	SCL-1	Scalability	Systems shall be designed to automatically scale (i.e. up and down) to accommodate the user load.		Y		Application Platforms & Delivery Branch (APDB)			Y
	SCL-2	Scalability	Systems shall be able to begin accepting requests within 15 seconds during cold start situations.		N		Application Platforms & Delivery Branch (APDB)			N
	SCL-3	Scalability	Systems shall the ability to operate in a shared environment so that resources can be allocated on demand.		Y		Application Platforms & Delivery Branch (APDB)			Y
	SEC-1	Security	Systems' shall use the FDIC's Secure Baseline Configuration Guide (SBCG) which is based on Security Technical Implementation Guides (STIGs) for all server implementations.		Y		OCISO/Cyber Risk Management Section (CRMS)	https://ncp.nist.gov/repository	STIGs	Y
	SEC-3	Security	Systems shall adhere to the guidance provided by the hosting platform team regarding computer security log management.		Y		Application Platforms & Delivery Branch (APDB)			Y
	SEC-5	Security	Systems shall use workstation certificates to validate computer authenticity.		Y		IOSB/Infrastructure Operation Management Section (IOMS)			Y
	SEC-6	Security	Systems shall adopt and implement FDIC's Enterprise-wide security standards, protocols and tools, which includes Cloud Authentication through standard authentication protocols (such as Security Assertion Markup Language (SAML) , OpenID Connect (OIDC), and OAuth2), and the use of FDIC's Cloud Security Stack.		Y		OCISO/Cyber Assurance Services Section (CASS)	e.g. Login.gov / ADFS for identity management, SkyHigh's Cloud Access Security Broker (CASB), etc.	SAML	N
	SEC-7	Security	System shall require authentication for all access attempts for any FDIC-owned component or platform and use phishing resistant multi-factor authentication (MFA), regardless of the user's location or network.		Y		IOSB/Infrastructure Operation Management Section (IOMS)			Y
	SEC-9	Security	Systems shall terminate an application session at the end of the session or after a predetermined amount of inactivity.		Y	Systems may preserve session state and should be compliant with FDIC policy.
The FDIC's current time out threshold is 15 minutes	Application Platforms & Delivery Branch (APDB)			Y
	SEC-10	Security	Systems shall provide users with their previous session state once the user reestablishes access using established identification and authentication procedures through integration with FDIC's Cloud Security Stack or On-Premise Security.		Y		Application Platforms & Delivery Branch (APDB)			N
	SEC-11	Security	Systems shall accept and electronically verify Personal Identity Verification (PIV) credentials from other federal agencies through integration with FDIC's Single Sign-on Security Stack.	Not Applicable	Y		IOSB/Infrastructure Operation Management Section (IOMS)			Y
	SEC-13	Security	Systems shall enforce role-based and attribute-based security in support of FDIC's least privileged model for accessing resources.		Y	Including the following but not limited to:

- front-end access

- file access

- searches

- reporting

- analytics

- metadata	OCISO/Cyber Risk Management Section (CRMS)			Y
	SEC-14	Security	Systems shall enforce role-based and attribute-based and security that allows the system administrator to manage user access.		Y	Including but not limited to the following administrative areas:

- user roles/groups

- user role/group access privileges

- individual user access privileges

- reference data

- workflow processes	OCISO/Cyber Assurance Services Section (CASS)			Y
	SEC-16	Security	Systems shall adhere to the Privacy Act of 1974, which "establishes a code of fair information practices that governs the collection, maintenance, use and dissemination of information about individuals that is maintained in systems of records by federal agencies".		Y		OCISO/Privacy Staff	Privacy Act of 1974	Y
	SEC-17	Security	Systems shall adhere to National Institute for Standards in Technology (NIST) 800-53 (FDIC's adopted version). Please refer to the OCISO Security Controls Catalog on the OCISO SharePoint site.		Y	Security Controls Catalog URL: https://fdicnet.fdic.gov/content/ociso/home.html#FDICtabs-3

Systems that require authorization prior to January 2022 should adhere to NIST 800-53, Revision 4.

New systems that require authorization after January 2022 should adhere to NIST 800-53, Revision 5.	OCISO/Cyber Risk Management Section (CRMS)		NIST	Y
	SEC-18	Security	Systems shall adhere to OMB Memorandum M-10-23 Model Privacy Impact Assessment for Agency Use of Third-Party Websites and Applications, which requires Federal agencies to "take specific steps to protect individual privacy whenever they use third-party websites or applications to engage with the public. Among other requirements, the memorandum asks agencies to prepare an adapted Privacy Impact Assessment (PIA)".		Y	OCISO/Privacy Staff	OMB Memorandum M-10-23	Y
	SEC-19	Security	Systems shall adhere to OMB Circular A-130: Managing Information as a Strategic Resource along with OMB A-123A: Management’s Responsibility for Enterprise Risk Management and Internal Control which "establishes requirements for Federal privacy programs, assigns responsibilities for privacy program management, and describes how agencies must take a coordinated approach to implementing information security and privacy controls".		Y	OCISO/Privacy Staff	OMB Circular A-130, OMB Circular A-123A	Y
	SEC-20	Security	Systems shall provide a Privacy Act Notice at the point of collection to individuals about whom it collects PII regarding:

1) The authority that authorizes the PII collection and whether disclosure by the individual of such PII is mandatory or voluntary;

2) The principal…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated Oct 2, 2025.