Vendor security & risk assessment
Digital Future Group's Information Security Program
For a development vendor with access to your systems
Digital Future Group enforces every requirement of the security perimeter of a client account technically, rather than leaving it to individual discipline: location, device, network, identity, monitoring, evidence retention. The program produces a continuous, independently reviewable record for the client's own audit.
Get the full document-
7
independently verified conditions must all be true at once before a specialist is granted access to a client account.
Evidence: Every access provisioning action is recorded in the retained logs.
-
3
separate monitoring layers converge on a single dashboard.
Evidence: Every run of the automated pre-flight check before a working session is logged as audit evidence.
-
13 months
minimum retention of logs in immutable (write-once, read-many) storage.
Evidence: The full history is available by device and by specialist for the entire retention period.
How to verify (all three numbers): a security review under NDA covers the control evidence and audit trail described in Section 5, matched to the scope of the account under consideration.
The evaluator's problem
The questionnaire gap
A questionnaire answer is, by construction, a self-report as of the date it was filled in. It tells the buyer what the vendor says its program does. It does not, on its own, tell the buyer:
- whether the same control held true yesterday
- whether it holds for every engineer rather than most
- whether the vendor itself could reconstruct — a year from now, in front of the buyer's own auditor — that it held on a specific day
Third-party access, including the kind a development vendor holds inside a client's environment, is a growing share of how breaches happen.
48%
of breaches in 2025 involved a third party, a sharp rise from the 30%–35.5% range independently measured for 2024 by Verizon and SecurityScorecard.
Source: Verizon, 2026 Data Breach Investigations Report, press release, May 19, 2026 (48%). Verizon, 2025 Data Breach Investigations Report, press release, April 23, 2025, and SecurityScorecard, 2025 Global Third-Party Breach Report, March 26, 2025 (30%–35.5% for 2024). SecurityScorecard sells third-party risk ratings.
Evidence
How to verify Digital Future Group
On this page
- The evaluation framework by stage of the access lifecycle
- Digital Future Group's position at each stage
- The vendor-neutral table of policy-only and enforced answers
- The questions to ask any vendor that cites SOC 2 or HITRUST
In the document
Beyond the Questionnaire, Version 0.7: the full text of each control subsection of Section 5, the definitions of terms and the numbered references.
Under NDA only
A direct security review conducted under NDA, covering the specific controls, evidence, and reporting relevant to a prospective engagement — including the control evidence and audit trail described in Section 5, matched to the scope of the account under consideration.
Questions for any vendor
Where a vendor cites SOC 2 or HITRUST, these questions apply regardless of which vendor is answering them:
- Which report
- Which assessment type
- What period
- What exceptions
Contact: [email protected]
Reading the documents
SOC 2 and HITRUST
Both instruments describe something a third party issued, on a specific date, against a specific scope — never something a vendor asserts about itself.
SOC 2 reports are issued by independent CPA firms after an examination against the Trust Services Criteria, and each report covers a specific audit window and a specific set of controls, so its value is tied to the period and scope it states.
Each HITRUST result is issued only after an assessment performed by a HITRUST Authorized External Assessor Organization and a subsequent quality review by HITRUST itself.
Digital Future Group's own position on these two frameworks is straightforward and stated in the vocabulary each framework itself uses: “Our controls are designed in accordance with the SOC 2 Trust Services Criteria, and we deliver within our clients’ SOC 2-audited environments.” “We work within our clients’ HITRUST CSF-certified environments and structure our delivery so our clients pass their HITRUST assessments.” The evaluation questions above — what report, what period, what exceptions, what assessment type — remain the right ones to ask of any vendor making a compliance-adjacent claim, including this one.
Source: Beyond the Questionnaire, Version 0.7, Section 4.
Worked example
Four stages of access
Digital Future Group's position, in one sentence
Where a security questionnaire records that a policy exists, this program enforces the corresponding requirement with a technical control at the point of use and produces a continuous record the client's own audit can independently review.
Source: Beyond the Questionnaire, Version 0.7, Sections 2 and 5; facts current as of September 29, 2026.
-
Before access is granted
Before any specialist is granted access to a client account, seven independently verified conditions must all be true at once.
A gate that must be satisfied before provisioning happens at all.
Details: before access is granted
What to ask
What has to be true about a specific engineer, on a specific device, before that engineer can reach the client's systems, and who or what checks it?
What Digital Future Group enforces
The seven conditions of the clearance gate:
- a corporate, centrally managed device enrolled in the company's device-management platform
- an active, compliant VPN connection
- multi-factor authentication configured
- training current as of the access date
- a signed confidentiality agreement on file
- a confirmed, permitted work location
- any additional requirements the specific client has layered on top of the company's own baseline
The gate and the technical perimeter:
- Gate. Access to a client account is provisioned only after the clearance gate is satisfied in full.
- Location. Work on a client account is restricted to permitted jurisdictions. Location is enforced technically at four independent layers: the VPN gateway itself, the identity provider's conditional-access policy, device-management compliance status, and the monitoring layer, with an automated pre-session check as a fifth, final gate before any working session begins.
- Devices. Client work happens only on corporate-owned, centrally managed hardware. Every corporate device carries full-disk encryption and runs without local administrator rights for the end user.
- Network. Every client session runs over an always-on VPN with a fail-closed kill switch and full-tunnel routing. Each client project is assigned its own dedicated network egress point into that client's infrastructure.
Fail-closed kill switch — a network safeguard that cuts connectivity entirely if the managed VPN tunnel drops, rather than allowing traffic to fall back to an unmanaged connection.
- Identity. Multi-factor authentication is the enforced minimum standard for every account, using time-based one-time codes rather than SMS or push notifications delivered to personal devices.
What trail it leaves
Login events, location data and device-compliance snapshots, together with every access provisioning action, are retained for a minimum of 13 months in immutable (write-once, read-many) storage.
-
During the engagement
Three separate monitoring layers converge on a single dashboard.
Before every working session, an automated pre-flight check runs a full connectivity and leak test.
Details: during the engagement
What to ask
Does the access granted at the start stay static, or is it re-verified continuously, and does the vendor produce evidence of that re-verification the buyer can independently inspect?
What Digital Future Group enforces
Three separate layers:
- a compliance snapshot of the device itself
- continuous integrity and liveness verification of the monitoring agent running on that device
- network-origin data treated as the source of truth at the gateway level, so that no single layer can be spoofed without the other two flagging the inconsistency
Every account undergoes a periodic access review on a quarterly cadence. Company leadership has read-only visibility into the dashboard, with no ability to alter configuration or intervene directly in an active session.
What trail it leaves
- Every run of the pre-flight check — pass or fail — is logged as a discrete piece of audit evidence.
- VPN sessions, pre-flight check results and alerts are retained for a minimum of 13 months in immutable (write-once, read-many) storage, with a full historical view by device and by specialist for the entire retention period.
- The results of each access review, together with any monitoring alerts raised in the interim, are folded directly into the material available for the client's own audit.
- Access to the dashboard is itself logged.
-
When something goes wrong
Incident response follows a structured, six-stage model.
An attempt to access a client account from a restricted location is classified as a high-severity incident.
Details: when something goes wrong
What to ask
Does the vendor's monitoring produce the kind of record an incident investigation actually needs?
What Digital Future Group enforces
- The six stages are preparation, identification, containment, eradication, recovery, and lessons learned — the same structure long established by SANS's Incident Handler's Handbook.
- Incidents are categorized on a multi-level severity scale that weighs both the severity of the event and the criticality of the affected asset.
- Playbooks are maintained for common incident types and formally tested on a recurring annual schedule.
- Every incident is followed by a formal post-incident review on a fixed schedule after closure, feeding lessons learned back into the playbooks themselves.
- Notification scales with severity: higher-severity incidents are escalated up through company leadership and, where relevant, communicated to affected clients through an official company channel.
What trail it leaves
A specific question — who was connected, from where, on what device, on a specific date — can be answered directly from the record rather than reconstructed after the fact.
Source: Six-stage model: SANS Institute, Incident Handler's Handbook, 2012.
Vendor evaluation table
The same four stages apply to any development vendor. The table below restates the lifecycle as a set of questions a buyer can put directly to a vendor, alongside the distinction, at each stage, between an answer that describes a policy and an answer that describes an enforced, evidenced control.
| Lifecycle stage | Ask the vendor | A policy-only answer sounds like | An enforced, evidenced answer sounds like |
|---|---|---|---|
| Before access | What has to be true before an engineer reaches our systems, and who checks it? | "Our contractors agree to follow our security policy." | A defined, multi-condition gate (device, network, identity, training, location, agreement) verified before provisioning, applied to everyone granted access. |
| During the engagement | Does access stay static, or is it re-verified — and can I see evidence of that? | "We review access periodically." | Continuous, multi-layer monitoring converging on one dashboard, with a session-level check logged every time, and a periodic review that feeds directly into audit material. |
| When something goes wrong | Are you drawn into our incident response, and what record does your monitoring produce? | "We have an incident response plan." | A staged process with tested playbooks, severity-based escalation, and logs detailed enough to answer "who had access, from where, on what date." |
| When it ends | How fast, and how verifiably, is access removed? | "We deprovision access when a contract ends." | Same-day revocation tied to a defined offboarding trigger, independent of administrative scheduling. |
A vendor that can answer the right-hand column with specifics — not with a restated policy — is showing a program built around enforcement rather than around the questionnaire itself.
Source: Beyond the Questionnaire, Version 0.7, Section 6.
Also in the program
Beyond the stages
Confidentiality and access discipline
Every specialist who works with client material signs a confidentiality agreement before that work begins.
Access to internal information follows a need-to-know principle rather than a default-open one: information is available because a person's role requires it, not because they are inside the company. Sensitive internal processes are marked with a distinct confidentiality designation inside the company's own systems.
Security training
Security training is mandatory for every employee and is verified as a precondition of access to a client account.
The program covers seven areas: phishing recognition, password hygiene, confidentiality, insider threats, business-email-compromise and CEO-fraud patterns, handling of data in transit, and clean-desk/clean-screen discipline.
Client software on a delivery device
Client software on a delivery device is assessed through a consistent five-point framework before it is allowed onto the perimeter.
- what data the software collects
- what it is capable of detecting about the device or its environment
- where it transmits that data
- what privileges it requires to run
- whether granting those privileges would weaken the perimeter controls
Compensating measures are applied wherever the analysis identifies a gap, on a per-account basis, before the software is approved for use.
Mobile devices
A personal phone is never permitted to participate in the security perimeter.
A corporate mobile phone is issued only on grounds tied directly to the requirements of the engagement.
Discipline
A confirmed violation triggers an immediate response:
- immediate suspension from the account
- same-day revocation of access
- removal from any public-facing profile or communication channel associated with the account
Source: Beyond the Questionnaire, Version 0.7, Section 5; facts current as of September 29, 2026.
FAQ
Questions about SOC 2 and HITRUST
A buyer evaluating a development vendor will almost always encounter SOC 2 and HITRUST in some form, and the two are worth understanding on their own terms before asking any vendor about either.
What does a SOC 2 report cover?
SOC 2 is built on the Trust Services Criteria published by the AICPA's Assurance Services Executive Committee, covering five categories: security, availability, processing integrity, confidentiality, and privacy. The security category alone spans control environment, risk assessment, monitoring, logical and physical access, system operations, change management, and risk mitigation. That is exactly the set of questions a buyer should already be asking a development vendor directly, with or without a SOC 2 report in hand.
Source: AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus — 2022), TSP Section 100.
What should I ask a vendor that cites SOC 2?
The question a buyer can ask a vendor is not "what does your website say about SOC 2" but "may I see the report" — and, once it is in hand, "what does the exceptions section say, and what was the audit period."
What forms does a HITRUST result take?
HITRUST results come in three forms — e1 (essentials, one-year validity), i1 (one-year validity), and r2 (the deepest, risk-based assessment, two-year validity). The external assessment and HITRUST's quality review are what stand behind a result; a readiness self-assessment against the framework is an internal preparation step ahead of that process.
Source: HITRUST Alliance, HAA 2023-004: e1 Assessment Introduction, January 17, 2023.
What should I ask a vendor that cites HITRUST?
For HITRUST, the equivalent question is "which of the three assessment types, and when does it expire."
Source: HITRUST Alliance, HAA 2023-004: e1 Assessment Introduction, January 17, 2023.
Get the full document
