Which open-source tools produce HITRUST evidence for the domains that fail most
If a customer or contract now requires HITRUST, start with the domain that fails most. The HITRUST 2025 Trust Report says Endpoint Protection was the most common cause of failing domains in 2024, at 12.2% of failing domains. Open-source tools can generate evidence for endpoint, vulnerability, logging, access control and continuity, but your organization owns the controls, and an independent External Assessor decides the result. Tools produce evidence; they do not produce a pass.
The right tool set depends on your environment, your assessment scope and how evidence is uploaded to MyCSF. Endpoint evidence starts with inventory: osquery, run through the osqueryd daemon, can schedule SQL queries across a fleet and return running processes, loaded kernel modules, open network connections and file hashes. That output shows what is on laptops, desktops and mobile devices that can reach the in-scope environment, but only if your scope definition includes those devices and the query schedule covers them. Confirm the coverage of each query with your assessor before you rely on it.
Logging, vulnerability and access evidence follow the same logic. Wazuh decodes collected logs, compares events against its ruleset and writes alerts that can be reviewed in its dashboard. Greenbone Community Edition runs scans from a daily updated feed, and midPoint records access certification decisions with named reviewers. Bareos supports the continuity domain through backup, restore and verify jobs. Each tool needs its configuration, its scope and its output retained. Automated controls also need a test showing the system enforces the setting, not only a configuration export. Check the license terms of each component (osquery, Greenbone, Wazuh, midPoint and Bareos use different licenses) before you distribute or host them for others.
Why endpoint, vulnerability, logging, access and continuity cause failures
The 2025 HITRUST Trust Report identifies Endpoint Protection as the most common domain causing submitted assessments to fail certification in 2024. The four areas that follow are the other domains where evidence gaps tend to surface, and each one can be produced by a self-hosted tool if the output is captured in the form an assessor will accept.
Endpoint protection coverage
Endpoint Protection covers user laptops, desktops and mobile devices that can reach the in-scope environment, so the assessor first asks which devices are in scope and how that list was built. A complete, current inventory of endpoints is the starting point. Check whether the inventory includes unmanaged and personal devices, and whether the query results can be exported and dated for the assessment window.
Vulnerability scan evidence
Assessors look for scans that cover the in-scope assets on a defined schedule, with findings tracked to remediation or documented risk acceptance. A scanner that runs once and is never reviewed produces little usable evidence. Confirm which feed version was used for each scan, that authenticated scans were run where the requirement needs them, and that the scan scope matches the asset inventory.
Log collection and alert review
Logging requirements are tested by showing that security-relevant events are collected, analyzed and acted on, not just stored. Assessors will ask for a sample of alerts and the record of how each was triaged. Confirm that log sources are listed, that rules are documented and version controlled, and that retention and review responsibilities are written down before the fieldwork window opens.
Access review and segregation of duties
Access control is tested through evidence that access is granted on approval, reviewed periodically and removed when no longer needed. Access accumulation, where users keep roles from earlier jobs, is a common finding. Periodic certification campaigns with named reviewers and recorded decisions to keep, change or revoke access give assessors a traceable record. Confirm that reviewer independence and review periods are defined in your own policy.
Backup and restore testing
Continuity requirements are tested by showing that backups run, that they can be restored, and that restores are verified against a stated recovery expectation. A backup job log alone does not show recoverability. Ask for restore test records with dates, the files or systems restored, who performed the test and the result. Confirm the catalog retains the history needed for the assessment period.
Which tool produces evidence for each domain
Endpoint Protection was the domain that most often caused submitted assessments to fail certification in 2024, accounting for 12.2% of failing domains according to the HITRUST 2025 Trust Report. The domain covers user laptops, desktops and mobile devices that can reach the in-scope environment. osquery answers the first question an assessor asks: what is running on those devices at the time of testing. It exposes processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables, and its osqueryd daemon schedules those queries across a fleet of hosts.
- License: osquery is available under Apache-2.0 OR GPL-2.0-only, so the organization chooses the option that fits its distribution model. Confirm the choice with counsel.
- Scheduled results: osqueryd runs queries on a schedule, so results can be retained as dated, repeatable records of device state.
- Population coverage: osquery reports only on hosts where it is installed and running. A separate inventory of the in-scope device population is still needed.
- Limits: osquery does not show that an endpoint protection product is active, that patches are applied or that disk encryption is enforced unless you write queries for those specific settings.
Confirm which tables and query packs your osquery version exposes in its own documentation before you map them to requirement statements.
Vulnerability management evidence needs three things: a defined target scope, a scan that ran on known dates and a record of what was found and what happened next. Greenbone Community Edition, built on the OpenVAS Scanner, supplies the first two. Its scan engine runs vulnerability tests from the Greenbone Community Feed, which is updated daily, against target systems. The gvmd manager controls the scanner over the Open Scanner Protocol, and gvmd keeps the scan configuration and results that you export as evidence.
- License: Greenbone Community Edition is licensed under AGPL-3.0-or-later. If you modify the software and make it available to users over a network, the license terms apply to those modifications. Confirm your obligations with counsel.
- Feed version: Keep the feed date that appears with each scan. Without it, an assessor cannot tell which vulnerability tests were current when the scan ran.
- Target lists: Scan results only cover the targets you configured. Reconcile target lists against the asset inventory for the in-scope environment.
- Authenticated scans: Credentialed scans can check more settings than unauthenticated scans. Document which mode each scan used.
- Limits: A scan report does not show that findings were triaged, risk-accepted or remediated. Those decisions need tickets, approvals and a rescan trail.
Confirm the feed update behavior and scan configuration options in the Greenbone documentation for the version you deploy.
Logging evidence shows that security-relevant events were collected, analyzed and acted on. Wazuh decodes collected logs, compares each event against its ruleset and writes matching alerts to local files. The ruleset includes more than 3,000 built-in rules and decoders, plus any custom rules you add. Alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK and forwarded to the Wazuh indexer, where analysts review them in the dashboard. The alerts.json file is the most useful artifact for an assessor because it is machine-readable and can be sampled by date.
- License: Wazuh is licensed under GPL-2.0-only. Review how your deployment uses and distributes the software with counsel.
- Rule coverage: The built-in ruleset is large, but not every rule applies to every log source. Confirm which decoders and rules cover each source you collect from.
- ATT&CK mapping: The mapping helps with reporting and analysis. It does not prove that a particular attack would be detected.
- Source completeness: Wazuh analyzes only what is forwarded to it. Check that each in-scope system sends logs, and that time sources and retention settings match your requirements.
- Limits: Alerts do not show that a person reviewed them or closed them. Keep the ticket or case trail that links each alert to its disposition.
Confirm the rules and decoders for each log source in the Wazuh ruleset documentation for your version, then sample alerts across several dates to test the trail.
Access certification evidence shows that someone accountable reviewed who has access to what, and that unneeded access was removed. midPoint runs access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments. This counters access accumulation, where users gather permissions over time, and supports segregation of duties by making conflicting assignments visible to reviewers. The campaign record, with its scope, reviewers, decisions and timestamps, is the core evidence.
- License: midPoint is licensed under EUPL-1.2 or later. Confirm the license terms that apply to your deployment with counsel.
- Campaign record: Keep the campaign definition, reviewer assignments, each decision and its date. Those records show the review happened as designed.
- Revocation trail: A revoke decision only removes access if it reaches the target system. Verify that revocations were applied, not only recorded.
- Connector coverage: midPoint sees the identities and assignments it manages through its connectors. Accounts in systems it does not connect are outside the campaign.
- Limits: The tool cannot confirm that reviewers were independent of the access they reviewed. That control depends on your review assignment rules and their documented approval.
Confirm connector support and campaign reporting in the midPoint access certification documentation for your version before you rely on it for a domain.
Continuity evidence needs proof that backups ran, that they can be verified and that files can be restored when needed. Bareos covers the operational side. Its Director schedules and supervises backup, restore, verify and archive jobs, and it keeps a SQL catalog of the files it has backed up. You can restore files from the current backup or from a backup taken before a given date and time, which supports point-in-time recovery testing. The job logs, verify results and catalog entries together form the record an assessor samples.
- License: Bareos is licensed under AGPL-3.0-only. Confirm how the license applies to your deployment and any modifications with counsel.
- Job history: Retain job logs and verify results. A successful backup job is only one data point.
- Catalog as inventory: The catalog shows which files were backed up and when. Use it to pick restore samples across different systems.
- Restore testing: Keep dated records of restore tests, including the target, the files restored and the result.
- Limits: A completed backup does not prove that recovery meets your recovery objectives. Encryption, offsite copies and key custody are configuration and operating choices you must document and confirm.
Confirm the restore and verify options in the Bareos documentation for your version, and upload evidence to MyCSF individually, since bundled zip files are not accepted under the HITRUST Assessment Handbook.
What tool output must look like to satisfy a HITRUST assessor
An assessor does not accept a tool's dashboard as proof on its own. For automated controls, the assessor expects two things: evidence of the system configuration and a test showing the system actually enforces that configuration. Under the Assessment Handbook (sections 11.4.18 and 11.4.19), the configuration evidence shows what is set, and the enforcement test shows it works. Illustrative example: for a password rule, export the configuration showing the minimum length and complexity settings, then capture a attempt by a test user to set a non-compliant password and the resulting block. Apply the same pattern to Wazuh alert rules, osquery scheduled queries or Bareos job settings. Plan the enforcement test before the assessment window opens, because a configuration export with no test is a common gap.
Policies and procedures used as evidence must be current, final and approved (Handbook sections 11.3.7 to 11.3.11). Tool output does not replace them. A scan report or access review export only counts when a referenced, approved procedure says why it runs, who reviews it and how exceptions are handled. Confirm each document's approval status and revision date in your own records before you upload it. Every artifact must be uploaded to MyCSF and linked to the specific requirement statement and maturity level it supports. Zip files and spreadsheets that bundle a domain's evidence are not accepted. Package each export on its own: one Greenbone scan report with its scope and date for the vulnerability requirement, one midPoint certification campaign record for the access requirement, and so on. Decide early who owns that packaging step, since re-cutting bundled exports under deadline pressure is where evidence most often gets rejected. Ask your External Assessor to confirm the expected file naming and linking convention before you start collecting.
How the tools get deployed and evidenced before fieldwork
This sequence turns a set of self-hosted tools into dated, attributable evidence that maps to each HITRUST requirement statement before the External Assessor arrives. The organization keeps ownership of every control while the implementation partner prepares the systems and the evidence pack.
Scope the in-scope environment
The organization and its implementation partner define which endpoints, servers, network segments, identity sources and applications fall inside the assessed environment, and which are excluded with a stated reason. Laptops, desktops and mobile devices that can reach in-scope systems are listed explicitly, since endpoint protection is among the domains most often tied to failed submissions. The output is a signed scope register with asset owners named for each population, which every later collection step draws from.
Deploy and configure each tool in your infrastructure
Engineers install osquery, Greenbone Community Edition, Wazuh, midPoint, Bareos and any other chosen tools inside the organization's own cloud accounts, data centers or air-gapped network, with access limited to named administrators. Configuration files, rulesets, scan targets, backup schedules and role catalogs are kept under version control so every change has an author and a date. The step is complete when each tool runs against a pilot set of hosts and its configuration is stored in the change record.
Define the collection schedule
The team sets how often each tool runs and how its output is retained: osquery scheduled queries across the fleet, vulnerability scans against the scope register, Wazuh alert review, midPoint access certification campaigns with named reviewers and deadlines, and Bareos backup, restore and verify jobs. The schedule is written down with the owner of each job, the storage location and the retention period, which the organization must confirm against its own policy. The output is a collection calendar that auditors can compare against the evidence actually produced.
Run a dry evidence pull
Before the assessment window, the team pulls one sample of each evidence type exactly as an assessor would receive it, including a configuration export and a test showing the system enforces that configuration. Automated controls need both the configuration and proof of enforcement, such as a user being blocked from setting a non-compliant password, so the dry run checks both halves. Each pull is logged with timestamp, system, operator and hash. The step closes when every planned evidence item has been produced at least once.
Review output against each requirement statement
A reviewer who is not the person who produced the evidence checks each item against the requirement statement and maturity level it supports, confirming it shows the control operating in the assessed environment and within the review period. Policies and procedures used as evidence are confirmed to be current, final and approved, and gaps in coverage are logged as corrective actions before fieldwork. The output is a traceability matrix linking each evidence item to its requirement and maturity level, with open gaps and owners recorded.
Upload evidence to MyCSF and hand over to the assessor
Each evidence file is uploaded to MyCSF individually and linked to its requirement statement and maturity level, because zip files and spreadsheets that bundle a domain's evidence are not accepted. The organization confirms the handover package with its External Assessor, including who answers questions, how samples are selected and where raw tool output is stored. The step is complete when the assessor confirms receipt and the internal owner holds a copy of every linked item.
What the licenses mean for an assessed organization
Each open-source tool in this stack carries its own license, and those terms decide what you must publish, share or disclose when you modify the software or hand it to someone else. Running a tool unchanged inside your own environment triggers few obligations, but the picture changes once you customize code, distribute binaries or host it for others. Confirm each point with counsel before you rely on it.
osquery under Apache-2.0 or GPL-2.0
The osquery project is available under Apache-2.0 OR GPL-2.0-only, which means you may choose the license that fits your use. Apache-2.0 is permissive and generally requires license notices and attribution when you redistribute. GPL-2.0-only is copyleft and, if you distribute a modified build, requires you to make the corresponding source available under the same terms. Record which license you elected for each deployment so the choice is traceable during assessment.
Greenbone Community Edition under AGPL-3.0
The scan engine is licensed AGPL-3.0-or-later. Beyond the GPL obligations, AGPL extends the source-availability duty to modified versions that users interact with over a network, so a customized scanner exposed as a service may trigger disclosure. Internal scanning of your own estate, with no modification, usually sits outside that trigger. Keep vendor feed terms separate from the software license, since the Community Feed has its own usage conditions.
Wazuh under GPL-2.0-only
Wazuh is licensed GPL-2.0-only. Modifying the agent or manager and distributing those binaries to a third party requires you to offer the corresponding source under GPL-2.0. Custom decoders and rules are configuration rather than linked code in most deployments, but confirm that your rules and integrations do not bundle GPL-covered code in ways that change the analysis. Document where you have modified Wazuh so your evidence set shows which version runs in production.
midPoint under EUPL-1.2 or later
midPoint is licensed under EUPL-1.2 or later, a copyleft license written for the European Union. Distribution of modified versions requires making source available under compatible terms, and EUPL defines its own compatibility list for combining code with other licenses. Access certification campaigns run inside your deployment and do not themselves create a distribution. Ask counsel whether any custom connectors you build need separate treatment before you ship them to a partner.
Bareos under AGPL-3.0-only
Bareos is licensed AGPL-3.0-only, so the network-use clause applies to any modified Bareos Director you expose to users or other organizations. Backup administration used only by your own staff rarely triggers that clause, but a managed backup service offered to clients can. Keep your backup configuration and catalog in your own environment, and record any patches so restore evidence reflects the version you actually operate.
When counsel must review terms
Obligations change with three facts: whether you modify the code, whether you distribute binaries outside your legal entity, and whether users interact with a modified version over a network. Map each tool against those facts for your use case, then have counsel confirm the result in writing. Your assessor will not interpret license terms for you, so the file should show who reviewed the licensing and when.
Open-source tooling or commercial tools for each domain
This table compares self-hosted open-source tools with commercial endpoint, scanning, SIEM and identity governance products on support, integration effort, vendor evidence exports and staffing. Read each row as a question to answer for your own environment, not as a ranking, since neither option is cheaper or faster by default.
| Domain need | Self-hosted open source | Commercial product |
|---|---|---|
| Endpoint protection (osquery) | osquery exposes endpoint state as SQL tables and osqueryd schedules queries across hosts. Your team builds the query packs, fleet enrollment and evidence exports. | Commercial endpoint suites usually ship managed agents, policy consoles and prebuilt reports. Confirm which HITRUST-relevant reports the vendor exports and whether they meet the MyCSF upload format. |
| Vulnerability management (OpenVAS) | Greenbone Community Edition runs the OpenVAS scan engine against the daily Community Feed. Scan scheduling, credentials, retention and remediation tracking sit with your team. | Commercial scanners typically include vendor support, authenticated scanning templates and ticketing connectors. Ask for scan history exports that show the scope and date of each run. |
| Logging and monitoring (Wazuh) | Wazuh decodes logs, applies its ruleset of over 3,000 built-in rules and decoders plus custom rules, and writes alerts for review in its dashboard. Your team tunes rules and owns storage sizing. | Commercial SIEM platforms often provide vendor-maintained detection content, hosted storage and formal support tiers. Confirm log retention and alert export formats before relying on them as evidence. |
| Access control and recertification (midPoint) | midPoint runs access certification campaigns in which designated reviewers keep, change or revoke role assignments within a set timeframe. Your team designs campaigns and keeps the decision records. | Commercial identity governance products usually offer packaged review workflows, connectors to common directories and vendor support. Confirm how decision history is exported for the assessor. |
| Continuity and backup (Bareos) | Bareos schedules backup, restore and verify jobs and keeps a SQL catalog of backed-up files. Restore tests, offsite copies and recovery timing evidence are your responsibility. | Commercial backup platforms often include vendor-run support, appliance options and built-in restore reporting. Confirm whether restore test logs can be linked to each requirement in MyCSF. |
| Staffing and ownership | Expect internal engineers to operate, patch and document each tool, and to answer assessor questions about configuration. Community support varies, so plan for a named owner. | Vendor support contracts add a service channel and roadmap, but licensing and admin roles still need internal owners. Ask who performs configuration evidence reviews. |
| Assessor evidence rules | Automated controls need configuration evidence plus a test showing enforcement. Policies used as evidence must be current, final and approved, and uploads must be linked per requirement, not bundled. | The same evidence rules apply regardless of tooling. Ask the vendor for exports you can upload individually, not summary dashboards alone. |
What must be in place before the assessor arrives
An assessor will test whether the tools in this stack are running, scoped and producing evidence that holds up. Each item below is a precondition to confirm against the current assessment scope before fieldwork starts, not after.
Endpoint coverage across the full scope
Confirm that osquery or another agent is deployed on every in-scope laptop, desktop and mobile device that can reach the environment, not only on servers. Endpoint Protection was the most common domain causing submitted assessments to fail certification in 2024, so gaps in this inventory are a known failure path. Reconcile the osquery fleet against your asset register and list any device that cannot report.
Documented and approved policies
Each tool's control needs a written procedure that is current, final and approved before the assessor samples it. Drafts, unsigned versions and policies that describe a different tool version will be rejected as evidence. Check that every procedure names the tool, its owner, its review date and the approver.
Evidence retention and upload
Decide how long Wazuh alerts, scan reports and Bareos job logs are kept, and confirm they can be retrieved for the full assessment period. Evidence must be uploaded to MyCSF and linked to each requirement statement and maturity level, so a zip archive or spreadsheet bundle will not be accepted. Build a mapping from each requirement to the exact file, date and system that produced it.
Enforcement test plan for each control
For every automated control, the evidence needs two parts: the configuration of the tool and a test showing it enforces the control. For example, show the osquery query that flags a disabled firewall alongside a test host that is flagged, or a Wazuh rule firing on a simulated failed login. Record the test date, the tester and the result for each tool.
Access reviews with recorded decisions
Run a midPoint certification campaign for in-scope systems and keep the reviewer decisions to keep, change or revoke each access item. Reviewers must act within the timeframe you set, and unreviewed items are a finding. Keep the campaign definition, reviewer list and completed decisions as separate, dated records.
Scope confirmed against the current assessment
Before fieldwork, confirm the in-scope systems, locations and endpoint population against the current assessment scope and CSF version, since requirement statements change between releases. Ask your External Assessor to confirm the scope in writing. Any tool that touches an in-scope system must be included, and any excluded system needs a documented reason.
Who owns the controls, the tools and the report
The organization owns its controls, the tools that produce evidence, and the accuracy of everything submitted. Open-source tools do not change that: a scanner, a log pipeline or a backup job is only evidence if the organization decides what it covers, runs it as designed and can show it working over time. Ownership stays with the organization's security, IT and compliance leaders even when a partner installs the tools.
- Control ownership: Decide which endpoints, scan targets, log sources, accounts and backup sets are in scope, and accept the risk of any requirement marked not applicable.
- Tool operation: Staff the daily running of osquery, Greenbone, Wazuh, midPoint and Bareos, including alert triage, access review decisions and restore testing.
- Evidence accuracy: Confirm that exports, reports and configuration screenshots are current, final and approved before upload to MyCSF, and that each item links to the right requirement statement.
- Policy currency: Keep the policies and procedures that the tools enforce approved and up to date, since outdated documents are not accepted as evidence.
- Quote and contract: Confirm in writing which tasks the organization keeps and which move to a partner.
Before engaging anyone, check that a named internal owner can answer for each tool's output during fieldwork.
DeployOpen is an implementation partner. It plans, deploys, configures, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, then prepares the systems and evidence that the organization will present. DeployOpen does not issue HITRUST reports, validated assessment results or certifications, and it does not act as the External Assessor. Its work is scoped and delivered in writing before it starts.
- Planning: Map each HITRUST domain in scope to a tool, a data source and a retention path, and agree the boundaries in a fixed-scope document.
- Deployment: Install and configure the tools in the client's cloud accounts, data centers or air-gapped networks, including agents, rulesets, scan schedules and backup policies.
- Evidence preparation: Produce configuration records and test cases for automated controls so the organization can show both the setting and its enforcement.
- Documentation: Write runbooks and records that explain how each tool is operated, reviewed and changed.
- Support: Provide upgrades and continuous operation through a retainer where the client chooses it.
Ask any partner to state, in the statement of work, that it will not sign or issue assessment results.
Only an Authorized HITRUST External Assessor organization may perform the validated assessment submitted for certification. The assessor tests the evidence and the implementation during fieldwork, and HITRUST performs central quality assurance before it issues the report. The assessor is independent of the organization's readiness work, which is why the assessor's role differs from the partner's role even when the same tools are involved.
- Testing: Sample evidence, inspect configurations and test automated controls, including whether the system actually enforces a setting.
- Fieldwork window: Complete validated fieldwork within the window set in the HITRUST Assessment Handbook, which is at most 90 days for e1, i1 and r2.
- Submission: Submit results to MyCSF, where evidence must be linked to each requirement statement and maturity level.
- Quality assurance: HITRUST reviews the submission before any report or certification is issued.
- Independence: Confirm the assessor's independence rules before hiring a partner to do related work.
Confirm with the External Assessor which tools, configurations and evidence formats it will accept before the tools are deployed.
Questions teams ask before deploying these tools for HITRUST
Are open-source tools accepted as evidence for HITRUST assessments?
Yes, but the tool is never the evidence on its own. An assessor accepts output only when it shows the control working in your environment. For automated controls, the Assessment Handbook expects evidence of the system configuration plus a test showing the system enforces it, such as a user being blocked from setting a non-compliant password. Every piece of evidence must be uploaded to MyCSF and linked to the relevant requirement statement and maturity level. Zip files and spreadsheets that bundle a domain's evidence are not accepted, so plan exports that map cleanly to individual requirements. Policies used as evidence must also be current, final and approved. Read the Assessment Handbook before you design your collection process.
How much effort does HITRUST evidence collection take with open-source tools?
Effort depends on how many systems are in scope and how many control areas the tools cover. The licenses do not set the effort. Endpoint protection is a useful reference point: the HITRUST 2025 Trust Report says it was the most common domain causing submitted assessments to fail certification in 2024, at 12.2% of failing domains. Expect work in four places: deploying agents or scanners across the in-scope fleet, tuning queries and rules until output is repeatable, building evidence exports linked to requirement statements, and reviewing results on a schedule so gaps appear before fieldwork. Costs come from the staff doing this work and from any partner's fee, which should follow a written scope. Ask any partner to itemize setup, tuning, evidence mapping and handover separately, and to state which tasks recur after the assessment.
Can an internal team produce HITRUST evidence without outside help?
A capable internal team can deploy and run these tools alone, and many organizations do. Outside help is usually sought for speed, configuration depth and evidence mapping. The organization still owns its controls. Whoever does the work, only an Authorized HITRUST External Assessor can perform the validated assessment, and HITRUST performs quality assurance before reports are issued. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares systems and evidence for assessment. DeployOpen does not issue reports or certifications. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any provider, including your own team's plan, to show which tasks stay in-house and which move to a partner.
How does the 90-day fieldwork window affect evidence collection?
The validated assessment fieldwork window is at most 90 days for e1, i1 and r2 assessments. The window limits how long the assessor tests, so the evidence they sample must already exist and be stable when fieldwork begins. Set up collection to run continuously beforehand. Scheduled osquery queries, Wazuh alert exports, Greenbone scan reports and Bareos job logs each produce dated records you can point to. Avoid building a configuration baseline during fieldwork, because the assessor needs to see the system as it actually operated. Assign a named owner to each evidence stream and keep an index that links every file to its requirement statement, so questions during fieldwork are answered quickly from the index.
What does this work need from internal staff?
Plan for named internal owners, not only tool administrators. Each control needs someone who can explain the configuration, show that it is enforced and keep its evidence current. Typical roles include a system owner for each tool, a reviewer for access certification campaigns in midPoint who decides whether to keep, change or revoke each access item within the set timeframe, an owner who acts on Wazuh alerts, and an approver for policies. Staff must also answer assessor questions directly, so each team member should understand the output of the tools they operate. Confirm early with your assessor whether any internal testing will be relied on, since reliance depends on the testers' objectivity and staffing.
How can we confirm what these tools actually do?
Confirm capabilities by testing them in your environment, not by reading a feature list alone. Project documentation is the starting point. The osquery documentation describes how its SQL tables and the osqueryd daemon run queries across a fleet, and Wazuh documents its ruleset and decoders. Then run a proof: schedule one query, trigger one alert and demonstrate one enforced setting end to end, keeping the output as sample evidence. Check licenses as well. Greenbone Community Edition is AGPL-3.0-or-later and Bareos is AGPL-3.0-only, and both carry obligations if you modify and distribute them. Record test results in writing, and confirm anything the documentation leaves open with the maintainers or your legal team.
How DeployOpen fits the evidence work
DeployOpen plans, implements and hardens the open-source tools described on this page inside your own cloud accounts, data centers or air-gapped networks, so the endpoint, vulnerability, logging, access review and backup evidence is generated in systems you control. Before any work starts, DeployOpen agrees a written scope that names each tool, the HITRUST domains it supports, the hosts or environments it covers, the retention period for its output and the people who will review it. That written scope is what turns a list of software into a defined body of evidence. Ask any implementation partner to show you the scope document before you sign, and check that it names the requirement statements each tool is expected to support, since a tool that is installed but not tied to a requirement produces logs nobody can use in a validated assessment.
Once the scope is fixed, DeployOpen configures the components for hardening and repeatable collection. In practice this means deploying osquery queries on a schedule across the fleet, tuning Greenbone scan targets and credentials, reviewing Wazuh decoders and custom rules, setting midPoint certification campaigns with named reviewers and deadlines, and testing Bareos restore jobs on a schedule. DeployOpen then prepares evidence packages for each requirement: the configuration as it stands, a test showing the system enforces it, and the approved policy that governs it. These packages are uploaded to MyCSF individually and linked to the relevant requirement statements, because bundled zip files or spreadsheets are not accepted. DeployOpen does not issue HITRUST reports, validated assessment results or certifications. Only an Authorized HITRUST External Assessor organization can perform the validated assessment, and HITRUST performs quality assurance before it issues a report. Confirm the roles of each party in writing before you start.
How DeployOpen scopes, deploys and prepares HITRUST evidence
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the endpoint, vulnerability, logging, access and backup tooling that produces HITRUST evidence. We prepare systems and evidence for your assessment, while the organization owns its controls and an independent External Assessor performs the validated assessment.
How we scope
- We agree a written scope listing which tools, hosts, domains and environments are in scope before work starts.
- Scope names the HITRUST requirement areas each tool supports, so evidence owners know what they must produce.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any build begins.
How we build
- We deploy the agreed tools in your cloud accounts, data centers or air-gapped networks, under your change control.
- We configure automated checks and test that each control both exists in configuration and enforces the rule in practice.
- We confirm the open-source licenses of each component and record any terms your legal team must review.
How we hand over
- You receive configuration records, test results and runbooks, organized so evidence can be uploaded to MyCSF against each requirement.
- We document evidence age, collection method and owner for each artifact, so your assessor can judge currency and sampling.
- We walk your team through operation, so your staff can produce and explain evidence without relying on us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
- We can prepare evidence refreshes ahead of an interim or renewal assessment, to the extent your scope includes them.
- Questions about whether a tool's output meets your assessor's rules should go to your External Assessor, which we can help you prepare for.
