Attachment B.xlsx
XLSX spreadsheet 11 KB Posted
- Attached to
- CORE MANAGEMENT SOFTWARE
- Solicitation number
- 5400030147
- Issued by
- Charleston County, South Carolina
About this file
This document is a security requirements shortlist (Attachment B) for a Research Request for Proposal (RFP) issued by a South Carolina healthcare research department seeking core management software. The shortlist serves as an initial comparative screening tool to evaluate the security capabilities of proposed solutions and does not constitute a detailed risk assessment. The evaluation framework comprises 15 security domains organized into six categories: Data & Research Governance, Research Compliance, Architecture & Hosting, Identity & Access, Security Assurance, Technical Protection, Logging & Incident Response, Resilience, and Third Parties/Contracts/Exit. Each domain contains specific comparative requirements or questions that vendors must address regarding data collection, permitted uses, compliance support, system architecture, hosting locations, data separation, single sign-on capabilities, multi-factor authentication, role-based access controls, security certifications, encryption protocols, audit logging, availability commitments, and subprocessor management.
The shortlist functions as a standardized evaluation matrix designed to rapidly compare vendor responses across critical security capabilities relevant to healthcare research operations. Vendors are required to provide detailed explanations addressing data governance practices, compliance with research protocols and regulatory requirements, complete architecture and data-flow documentation, identity and access management capabilities, current independent security assurance evidence, encryption and key-management procedures, customer-accessible audit logging with incident notification timeframes, resilience commitments including recovery time and recovery point objectives, and disclosure of all subprocessors with associated contractual agreements and data exit procedures. This structured approach enables the healthcare research department to efficiently assess vendor security postures during the initial proposal evaluation phase before advancing finalists to more comprehensive risk assessment procedures.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Amendment 1.pdf | ||
| Attachment A.docx | DOCX document | |
| Attachment C.xlsx | XLSX spreadsheet | |
| RFP.docx | DOCX document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Research RFP Shortlist
| Attachment B Security Questions and Requirements |
| Purpose: rapidly compare the security capabilities of proposed solutions for a healthcare research department. This shortlist is an initial comparative screening tool and does not replace the detailed risk assessment for finalists. |
| ID | Security Domain | Comparative Requirement / Question | Vendor Response |
| 1 | Data & Research Governance | Identify every category of organizational or research data the solution will collect, receive, create, access, transmit, store, or analyze. | |
| 2 | Data & Research Governance | List the specific data elements required by the solution and explain why each is necessary. | |
| 3 | Data & Research Governance | Explain every permitted use of organizational data, including research, analytics, product improvement, artificial intelligence, and model training. | |
| 4 | Research Compliance | Describe how the solution supports restrictions established by the protocol, IRB approval, participant consent, data-use agreement, sponsor, or funding agency. | |
| 5 | Architecture & Hosting | Provide a current architecture and data-flow diagram showing systems, integrations, trust boundaries, users, transfers, storage, backups, support paths, and subprocessors. | |
| 6 | Architecture & Hosting | Identify all hosting providers, countries, cloud regions, backup locations, disaster-recovery locations, and locations from which support personnel may access data. | |
| 7 | Architecture & Hosting | Describe how customer and study data are logically or physically separated from other customers and studies. | |
| 8 | Identity & Access | Does the solution support enterprise SSO through SAML 2.0 or OIDC, and can local passwords be disabled? | |
| 9 | Identity & Access | Can MFA be enforced for every privileged, administrative, support, service, and remote-access account? | |
| 10 | Identity & Access | Describe role-based controls and whether access can be restricted by study, protocol, site, research team, dataset, function, and environment. | |
| 11 | Security Assurance | Provide current independent security-assurance evidence applicable to the offered product and hosting environment. | |
| 12 | Technical Protection | Describe encryption in transit, at rest, in backups, and during system-to-system transfers, including key-management responsibilities. | |
| 13 | Logging & Incident Response | Describe customer-accessible audit logging and state the contractual incident-notification timeframe and post-incident support commitments. | |
| 14 | Resilience | State the availability commitment, RTO, RPO, backup frequency, restoration-testing frequency, and most recent recovery-test result. | |
| 15 | Third Parties, Contracts & Exit | List all subprocessors; confirm willingness to sign required agreements; explain data export and secure deletion; and identify security features requiring added cost. |
File details come from the government source that posted it. Updated .