HECVAT Category
Data
Data covers controls and questions related to that domain. It outlines expectations institutions typically require from vendors. The category helps assess risk posture and operational maturity. It provides structure for consistent evaluation during security reviews.
Assessment Questions
Will the institution's data be stored on any devices (database servers, file servers, SAN, NAS, etc.) configured with non-RFC 1918/4193 (i.e., publicly routable) IP addresses?
The concern here is network exposure, namely whether institutional data lands on devices using publicly routable IP addresses rather than private RFC 1918/4193 ranges.
Is the transport of sensitive data encrypted using security protocols/algorithms (e.g., system-to-client)?
Encryption in transit is the subject here: reviewers want confirmation that sensitive data is protected as it moves between systems, such as from your servers to a client's browser or mobile app.
Is the storage of sensitive data encrypted using security protocols/algorithms (e.g., disk encryption, at-rest, files, and within a running database)?
Encryption of data at rest is what reviewers are confirming here: whether sensitive stored data is protected using sound protocols and algorithms across disks, files, and running databases. Encryption at rest means that data is encrypted when it is stored on disk, in databases, or in other storage systems, as opposed to when it is being transmitted or actively processed.
Do all cryptographic modules in use in your solution conform to the Federal Information Processing Standards (FIPS PUB 140-2 or 140-3)?
FIPS validation is at the center of this requirement: every cryptographic module in your solution should conform to Federal Information Processing Standards 140-2 or 140-3.
Will the institution's data be available within the system for a period of time at the completion of this contract?
Post-contract data access is the subject here: whether the institution's data stays available within your system for some defined window after the engagement ends. This is important for several reasons:
Are ownership rights to all data, inputs, outputs, and metadata retained even through a provider acquisition or bankruptcy event?
Data ownership through disruptive events is the heart of this item: whether you retain rights to all data, inputs, outputs, and metadata even if a provider is acquired or goes bankrupt.
Do backups containing the institution's data ever leave the institution's data zone either physically or via network routing?
Where backups live and travel is the concern here, specifically whether any backup of the institution's data ever leaves its defined data zone, physically or through network routing. The 'data zone' refers to the physical and network boundaries where the institution maintains direct control over its data.
Is media used for long-term retention of business data and archival purposes stored in a secure, environmentally protected area?
Archival media storage is the concern: institutions want to know that long-term and backup business data lives in a secure, environmentally controlled location. 'Media' here refers to physical storage devices like backup tapes, external hard drives, optical discs (CDs/DVDs), or other physical storage formats used for data that must be retained for extended periods.
At the completion of this contract, will data be returned to the institution and/or deleted from all your systems and archives?
End-of-contract data handling is under review here, covering whether institutional data is returned to the customer or deleted from all your systems and archives once the engagement ends. Specifically, it wants to know what happens to the institution's data when your business relationship ends.
Can the institution extract a full or partial backup of data?
Data portability sits at the heart of this requirement, asking whether the institution can pull a full or partial backup of its own data out of your system. This is important for several reasons:
Do current backups include all operating system software, utilities, security software, application software, and data files necessary for recovery?
Recoverability is the real subject: assessors want backups complete enough to rebuild a system in full, covering operating systems, utilities, security and application software, and data files. Specifically, it's asking if your backups include ALL of the following components:
Are you performing off-site backups (i.e., digitally moved off site)?
Off-site backups are the focus, meaning copies of data that are digitally moved away from your primary systems so they survive a failure at the main location. 'Off-site backups' means that backup data is transferred (usually digitally) to a separate geographical location from where your primary systems operate.
Are physical backups taken off-site (i.e., physically moved off site)?
Off-site backup handling is the concern: this asks whether you physically move backup media, such as tapes or drives, to a location separate from where your primary systems run.
Are data backups encrypted?
Backup encryption is what's being verified here, namely whether the data backups your organization creates are themselves encrypted. Data backups are copies of important information stored for recovery purposes in case the original data is lost, corrupted, or compromised.
Do you have a media handling process that is documented and currently implemented that meets established business needs and regulatory requirements, including end-of-life, repurposing, and data-sanitization procedures?
Media lifecycle management is what reviewers are checking: whether you have a documented, active process covering hard drives, USB drives, backup tapes, and similar media. Media handling includes how you manage, store, transport, and eventually dispose of storage media that contains data.
Does the process described in DATA-15 adhere to DoD 5220.22-M and/or NIST SP 800-88 standards?
The standard being checked here is whether the data sanitization process described in DATA-15 conforms to DoD 5220.22-M and/or NIST SP 800-88 for secure destruction.
Does your staff (or third party) have access to institutional data (e.g., financial, PHI, or other sensitive information) through any means?
Insider and third-party access to institutional data is what's under review, including any path by which your staff or contractors could reach financial, PHI, or other sensitive information. Institutional data typically includes personally identifiable information (PII), protected health information (PHI), financial records, student records, research data, or other confidential information.
Do you have a documented and currently implemented strategy for securing employee workstations when they work remotely (i.e., not in a trusted computing environment)?
Remote work introduces risk outside your trusted network, and this item looks for a documented, actively enforced strategy for securing employee workstations wherever they operate.
Does the environment provide for dedicated single-tenant capabilities? If not, describe how your solution or environment separates data from different customers (e.g., logically, physically, single tenancy, multi-tenancy).
Tenant isolation is the subject of this question: whether you offer dedicated single-tenancy and, if not, how your environment keeps one customer's data separated from another's.
Are ownership rights to all data, inputs, outputs, and metadata retained by the institution?
Data ownership is what's being confirmed here: the institution wants assurance that it retains rights to all data, inputs, outputs, and metadata involved in the service. Specifically:
In the event of imminent bankruptcy, closing of business, or retirement of service, will you provide 90 days for customers to get their data out of the system and migrate applications?
Buyers asking this need reassurance about data portability if your business winds down, specifically a guaranteed window to extract data and migrate applications before the lights go out. It specifically wants to know if you will provide customers with a 90-day grace period to retrieve their data and migrate any applications before the service becomes unavailable.
Are involatile backup copies made according to predefined schedules and securely stored and protected?
The emphasis here is on involatile backups, copies written to persistent media like tape, disk, or cloud storage that retains data without power, made on a defined schedule and securely protected.
Do you have a cryptographic key management process (generation, exchange, storage, safeguards, use, vetting, and replacement) that is documented and currently implemented, for all system components (e.g., database, system, web, etc.)?
Cryptographic key management sits at the center of this requirement, namely whether you have a documented and active process covering key generation, exchange, storage, safeguards, use, vetting, and replacement across all system components. Cryptographic keys are the secret values used in encryption algorithms to secure data. The question specifically wants to know if you have processes for:
ResponseHub is the product I wish I had when I was a CTO
Previously I was co-founder and CTO of Progression, a VC backed HR-tech startup used by some of the biggest names in tech.
As our sales grew, security questionnaires quickly became one of my biggest pain-points. They were confusing, hard to delegate and arrived like London busses - 3 at a time!
I'm building ResponseHub so that other teams don't have to go through this. Leave the security questionnaires to us so you can get back to closing deals, shipping product and building your team.

