What HITRUST 17 Risk Management asks organizations to prove
Domain 17 Risk Management covers the organization's risk assessment and treatment process, including formal authorization of systems before they are used and periodic reviews of risk. If a HITRUST assessment is coming and this domain is unfamiliar or already failing, the first task is to show that risk is assessed, decided and revisited by people with the authority to accept it, and that those decisions leave a trail an assessor can follow from start to finish. The domain does not ask for a particular risk methodology. It asks whether the organization's own process produces dated, owned and repeatable decisions about the systems in scope. Management sign-off is the point of the domain. A risk assessment that no accountable manager reads, approves or declines does not reduce anything, because nobody has agreed to live with the residual exposure. Assessors therefore look for a named owner who authorizes each system before it handles in-scope data, a record of the conditions attached to that approval, and a review that reconsiders the decision when the system, its data or its threats change. Confirm who holds that authority in your organization, whether it is written down, and whether the people in those roles actually signed the decisions you plan to show.
The domain is hard in practice for three reasons. First, authorization often happens informally, through a deployment ticket or an email from a product lead, so the decision exists but cannot be produced on demand. Second, periodic reviews tend to be calendar events rather than triggered reviews, so a system changed in March may still carry a risk statement from the previous year. Third, the requirements in this domain connect to change management, so the evidence for a single system can sit in several places at once. An illustrative example: a new reporting service goes live with a sign-off recorded only in a chat thread, and the next risk review is three years overdue. Both gaps are the kind of finding that drives corrective action plans, so start by inventorying every in-scope system and checking whether each one has an authorization record and a current review.
Which systems, teams and third parties fall under risk management scope
Risk management scope in a HITRUST assessment follows the in-scope environment, not the whole organization. The cards below cover the systems that need formal authorization, the people who own risk decisions, and the third parties whose services touch in-scope data, plus two scoping choices that change the amount of work.
Systems that need formal authorization
Every system inside the assessed environment should have a recorded decision that management approved it for use before it went live, with a review date attached. Domain 17 scores this directly, and HITRUST's 2025 Trust Report ranks a requirement for management to formally authorize new systems and review those authorizations among the most frequent corrective action plans. Check that your inventory matches what the assessor will sample, including systems added after the last review.
Owners of risk decisions
Name the individuals who accept, mitigate or transfer risk for each in-scope system, and confirm they have the authority to do so. Assessors look for a clear line from the risk register to a named executive, and they check whether the people who approve system use are the same people who review the risk. Gaps here usually appear as authorization records signed by staff with no documented mandate.
Third parties that touch in-scope data
Vendors that host, process or can reach in-scope data belong in the risk picture even when their controls are assessed in another domain. Record each one, its data flows and the risk decision that allowed the engagement. Third-party oversight itself sits in domain 14, so keep the two records consistent rather than duplicating them.
Change management touchpoints
Some change management requirements sit in this domain, so changes that alter a system's risk profile need to trigger a reassessment. Map which change types require a fresh authorization, such as new integrations, new data stores or altered access paths. Confirm the threshold with your assessor before the fieldwork window opens.
AI security requirements
If you pursue the AI security certification, its requirement statements add work to this domain. Inventory each AI system in scope, record who authorized its use, and document the risk treatment decisions behind it. Confirm the exact requirement count for your version with HITRUST before scoping, since the add-on changes the baseline.
Inherited risk from a cloud provider
When a cloud provider supplies in-scope infrastructure, the provider does not perform risk management for you, so this domain is only moderately inheritable. Your own authorization decisions, risk register and periodic reviews stay with you. Map which change management requirements the provider covers and which remain yours in your shared responsibility matrix.
How an assessor tests risk management in a HITRUST assessment
This table compares the four areas an assessor typically examines within the 17 Risk Management domain: risk assessment, risk treatment, system authorization and periodic review. Read each row as the question the assessor asks, the evidence they request, how they choose samples and where organizations most often receive findings. The main takeaway is that authorization records and review cadence are easy to overlook but are tested against dated, traceable proof.
| Test area | Evidence the assessor requests | Sampling logic and common findings |
|---|---|---|
| Risk assessment process | Documented risk methodology, risk register, asset and threat inputs, and approval records showing management reviewed the results | Assessor checks that the method was applied to the in-scope environment, not only written down. Common finding: the register does not cover systems that were later brought into scope. |
| Risk treatment decisions | Treatment plans for each risk, accepted-risk sign-offs by a named owner, and dated links to remediation tickets | Assessor samples several risks across severity levels and traces each to a decision. Common finding: accepted risks lack an approver or an expiry date. |
| System authorization before use | Authorization records for new systems showing management approval before go-live, with the risk review that supported it | Assessor selects systems deployed during the review period and compares go-live dates with approval dates. Common finding: systems placed in production before authorization, a gap that appears among HITRUST's most frequent corrective action plans. |
| Periodic risk review | Review schedule, meeting minutes or sign-offs, and evidence that changes to systems or threats triggered reassessment | Assessor checks that reviews occurred on the stated cadence and at significant change points. Common finding: reviews are scheduled but not evidenced, or the register is not updated after a major change. |
| Assessment timing and assessor role | Engagement scope, fieldwork plan and independent assessor report, produced within the validated fieldwork window | Fieldwork lasts at most 90 days. Only an Authorized HITRUST External Assessor performs the validated assessment. Confirm the assessor's status with HITRUST before contracting, since DeployOpen prepares evidence but does not issue reports. |
How to build the risk management process step by step
This sequence turns risk management for HITRUST domain 17 into a working process, from the method and owners through to a register, treatment plans, an authorization workflow and scheduled reviews, with each step ending in an artifact an assessor can examine.
Define the risk method and owners
Start by writing down how your organization assesses risk: the scale for likelihood and impact, the criteria that decide what is acceptable, and who may accept residual risk. Name an owner for the process and for each risk category, and get management to approve the document. The step is closed when a signed risk management standard exists, is version controlled, and names the people who hold each decision. Assessors look for this document first because every later artifact depends on it.
Inventory assets and the systems in scope
List the information assets, systems, services and data stores that fall within the assessed scope, and record an owner, a data classification and the business process each one supports. Include cloud accounts, SaaS tools and any system that connects to the in-scope environment. The step closes with an asset inventory that matches your scope statement and that someone reviews against the live environment. Gaps here usually surface later as systems deployed without any risk decision.
Identify threats and vulnerabilities
For each asset or asset group, record the threats that could affect confidentiality, integrity or availability, and the vulnerabilities that make those threats plausible. Draw on your vulnerability scan results, incident history, threat intelligence relevant to your sector, and input from engineering and operations. The output is a threat and vulnerability list linked to the asset inventory. You know the step is done when every in-scope asset has at least one documented threat review, even if the result is that no material threat was found.
Build the risk register
Score each identified risk using the method from step one, recording the inherent level, existing controls, the residual level after those controls, and the owner. Keep one register that links each risk to its assets and to the requirement statements it affects in your HITRUST assessment. The register is complete when every risk has a score, an owner and a review date set by the risk method. A register that exists only as a spreadsheet snapshot without change history will be hard to defend in an assessment.
Write treatment plans for each risk
For risks above your acceptance threshold, choose a treatment: reduce, transfer, avoid or accept. Record the controls that will reduce the risk, the person responsible, and the status of each action. Where you accept a risk, record who approved the decision and why. The step closes with a treatment plan for every risk outside tolerance, with accepted risks signed off by the owner named in step one. Treatment plans also feed the corrective action plans you will need if an assessment finds a gap.
Set up the system authorization workflow
Require that a system, significant change or new service is formally authorized by a named manager before it handles in-scope data. The workflow should collect a short risk statement, the controls in place, open risks, and the approver's decision, recorded in a ticketing or GRC tool. Test it with one or two recent deployments to confirm the path works in practice. The step is complete when you can show an authorization record for each system in the inventory, with a date and the approver's name.
Schedule periodic risk reviews
Set a review calendar that covers the full register, plus triggered reviews when systems change, a security incident occurs, or the threat picture shifts. Each review updates scores, treatment status and authorizations, and records what changed. The step is closed when the review schedule is approved, the first full review is minuted, and the register shows evidence of re-scoring. Reviews without minutes, or with unchanged scores across several cycles, tend to draw questions from assessors.
Which evidence artifacts pass domain 17
The risk register is the starting point for domain 17 evidence. An assessor expects a documented method for identifying threats and vulnerabilities, estimating likelihood and impact, and recording the result for each risk to the in-scope environment. The register should show who owns each risk, when it was assessed, what the assessment considered, and which rating method the organization uses. Assessors commonly sample entries and trace them back to the asset inventory and the systems in scope, so a register that names systems the organization no longer runs will raise questions.
- Method record: a dated risk assessment methodology that defines scales, criteria and the approval authority.
- Entry detail: each risk with an owner, asset or system reference, likelihood, impact, rating and the date it was last assessed.
- Scope linkage: entries that map to the systems, data and locations in the assessed scope.
- Change history: version control or an audit trail showing when ratings changed and who approved the change.
- Between-assessment upkeep: scheduled reassessment dates, triggered reassessments after material changes, and retired risks marked with a reason.
Before fieldwork, ask whether every sampled risk can be traced to a current owner and a current system. Confirm the exact rating method with your assessor and your HITRUST Assessment Handbook version, since requirements for assessment content can change with CSF releases.
A risk treatment plan records what the organization decided to do about each risk above its acceptance threshold: reduce it with a control, avoid it, transfer it, or accept it with a named approver. Assessors test whether the chosen treatment matches the risk rating, whether actions have owners and due dates, and whether accepted risks were approved by someone with authority to accept them. A plan that lists controls without linking them to the risks they address will usually be questioned.
- Decision per risk: the treatment option chosen, the rationale and the approver for each entry above threshold.
- Action tracking: owners, target dates, status and evidence of completion for each treatment action.
- Residual rating: a reassessed rating after treatment, so the reader can see what remains.
- Accepted risk records: signed acceptances with expiry or review dates, not open-ended waivers.
- Link to other domains: cross-references to the control evidence held in other domains, such as access reviews or vulnerability remediation.
Keep the plan current by reviewing overdue actions and expiring acceptances on a fixed cadence. Ask your assessor how they expect corrective actions from a prior assessment to appear in the plan, since HITRUST reports this requirement area among frequent corrective action plan topics.
Domain 17 includes a requirement for management to formally authorize new systems before they are used and to review those authorizations. The evidence is a dated record that shows the system was assessed for risk, the owner accepted the residual risk, and the authorization covered the scope in use at that time. Assessors look for an authorization before go-live, not a retroactive sign-off assembled for the audit, so the timing and the approver matter as much as the document.
- Authorization package: the system description, data types, hosting location, connected services and the risk assessment performed before use.
- Sign-off record: a named management approver with authority over the business process, plus the date of approval.
- Conditions: any conditions attached to approval, with an owner and a deadline for each.
- Re-authorization triggers: defined events, such as major architecture changes, new data types or new third-party hosting, that require a fresh authorization.
- Periodic review of authorizations: a dated review confirming that each authorized system is still in use, still in scope and still within its conditions.
To keep this live, add an authorization step to the change or onboarding workflow so that no in-scope system goes into production without a record. Check with your assessor how systems deployed on the organization's own infrastructure, including those built by a platform partner, should be documented.
Periodic reviews show that risk management continues between assessments. Assessors expect minutes or formal records from management reviews that cover the risk register, open treatment actions, accepted risks and authorizations. The minutes should show who attended, what was reviewed, what decisions were made and which actions were assigned. A review that lists agenda items without decisions gives the assessor little to test.
- Review schedule: a documented cadence set by the organization, with the next review date visible.
- Attendance and authority: named attendees with the management roles needed to accept risk and assign resources.
- Decisions and actions: recorded outcomes for each item, including changes to ratings, new risks and closed actions.
- Input evidence: the reports or extracts reviewed, such as overdue actions, incident trends and changes in the environment.
- Follow-through: evidence that actions from the previous review were closed or escalated.
Run the review on the schedule you publish, and keep the minutes in the same repository as the register so they can be sampled together. Ask your assessor whether they expect a particular number of review cycles within the assessment period, since that expectation depends on the assessment type and the assessor's sampling approach.
Some change management requirements sit in domain 17, so change records can serve as evidence that risk decisions were applied to real modifications. Assessors look for changes to in-scope systems that reference the risk assessment or authorization they relate to, and for evidence that high-impact changes were reviewed before implementation. Routine changes with no risk impact still need a record, but the emphasis is on changes that alter the risk picture.
- Risk reference: each significant change ticket links to the risk entry or authorization it affects.
- Impact assessment: a documented judgment of whether the change alters likelihood, impact or the authorized scope.
- Approval before deployment: evidence of approval by the designated authority prior to implementation.
- Post-change check: confirmation that the outcome matched the approved change and that any new risk was entered in the register.
- Emergency changes: a separate, later review that records the risk decision made under time pressure.
To keep this current, make the risk field mandatory in the change tool and review a sample of changes each period. Confirm with your implementation partner or assessor which change categories you need to tie to risk, since that scope should be agreed before the assessment begins.
How domain 17 affects your pass or fail result
Each domain must clear its own average, so a weak Risk Management score can fail an assessment that is otherwise strong. HITRUST scores results across 19 assessment domains, and the thresholds apply per domain rather than to the assessment as a whole. For an e1 or i1, the core requirement statements in each domain must average at least 83. For an r2, each domain must average at least 62 across all of its requirement statements. Technical strength in access control, logging or encryption does not offset a low average in 17 Risk Management. The organization should read the threshold for its own assessment type in the HITRUST Assessment Handbook before planning its readiness work, since the scoring rules differ between e1, i1 and r2.
Authorization gaps are the usual reason this domain falls short. The HITRUST 2025 Trust Report lists Risk Management as 9.8% of failing domains in 2024, tied for second, and ranks the requirement for management to formally authorize new systems and review those authorizations eighth among the most frequent corrective action plans. In practice, the failure pattern is an authorization record that is missing, dated after the system went live, or never reviewed after a significant change. A new service may have strong encryption and monitoring and still produce a low score here because no one formally approved it for use in scope. A useful pre-assessment check is to list every system, data flow and AI capability in the assessed scope and confirm that each has a signed authorization, a named owner and a documented periodic review.
Because the thresholds are per domain, the practical planning question is whether the organization can show dated, approved authorization decisions for everything in scope before the fieldwork window opens. The domain also depends on the scope of the assessment. If the organization pursues the AI security certification, HITRUST places AI security requirement statements in this domain, so the number of statements that must average above the threshold grows. Organizations should confirm with their assessor which statements apply to their assessment type and version before setting internal targets, and should treat authorization records as evidence that needs to exist well ahead of the assessment rather than something assembled during it.
What drives the cost of meeting risk management
Meeting the 17 Risk Management domain is mostly staff time, with a smaller set of tooling and assessor costs. Each component below is either a one-time build or a recurring upkeep item, and the scope of systems, third parties and AI security requirements moves most of them.
Risk method design
A one-time effort to define how risks are identified, scored, accepted and treated, and who approves each decision. The organization pays its own staff or an outside consultant for this design work, and the cost rises with the number of business lines and system types in scope. Ask any consultant to show how the method maps to the requirement statements in this domain before agreeing a fixed scope.
Management and system owner time
Authorizing a new system before use and reviewing that authorization on a schedule takes time from managers and system owners, not only from security staff. This is a recurring cost, because each new system, material change or periodic review needs a signed decision. Estimate it by counting how many systems and owners are in scope and how often they must sign off.
Risk register and workflow tooling
A risk register, approval workflow and review reminders can be a spreadsheet, a ticketing queue or a dedicated governance tool. Licensing and hosting are recurring costs, while configuration and migration are one-time. Open-source options can lower license fees, but the organization still pays for setup, integration and administration, so ask a quote to separate those items.
Third-party and AI scope
The number of third parties that touch in-scope data and whether AI security requirements apply both raise effort in this domain. Each third party needs a documented risk decision, and AI security requirements add statements that the organization must evidence. Confirm the exact requirement count for your assessment type with HITRUST's current handbook and your assessor before budgeting.
Evidence upkeep between assessments
Keeping risk decisions, authorization records and review minutes current is a recurring cost that runs throughout the assessment cycle, not only before fieldwork. Assessors sample dated records, so gaps in the review history are costly to repair. Ask your readiness provider how evidence will be collected, stored and checked on a regular cadence.
Readiness review and assessor fieldwork
An external readiness review is a one-time cost that finds gaps before the validated assessment. Assessor fieldwork is paid to an Authorized HITRUST External Assessor organization, and its length is set by the assessment window, so unclear evidence extends effort. Only the assessor issues the report, so confirm in writing which work the readiness provider performs and which the assessor performs.
What meeting risk management costs in money and effort
This table breaks the cost of meeting the 17 Risk Management domain into its components, showing who is paid, whether each cost is one-time or recurring, what drives it, and how to reduce it. Read it as a checklist for comparing quotes, since the largest variable is usually internal time rather than licenses.
| Cost component | One-time or recurring, and who is paid | Main cost driver | How to reduce it |
|---|---|---|---|
| Tooling and licenses | Recurring for commercial GRC platforms; one-time setup for self-hosted tools. Paid to vendors, not to the assessor. | Number of users, frameworks loaded and whether the platform is hosted by the vendor or run in your own infrastructure. | Self-hosted open-source GRC tooling can remove license spend, though hosting, patching and backup still need budget. Confirm the license terms before adopting any tool. |
| Internal risk and authorization work | Recurring. Paid as staff time for risk owners, system owners and the security team. | Number of systems requiring formal authorization before use and how often authorizations are reviewed. | Standardize one authorization template and tie reviews to change events so each review does not start from zero. |
| Internal management time | Recurring. Paid as executive and manager time for risk acceptance decisions and periodic risk reviews. | How many risks need a named decision-maker and how often management meets to review them. | Keep a single risk register with clear owners and decision thresholds so management reviews focus on exceptions. |
| Evidence upkeep | Recurring. Paid as staff time, often inside operations teams. | Volume of authorization records, risk treatment decisions and review minutes that must be kept current across the assessment period. | Capture evidence at the point of decision, such as in the change ticket or approval workflow, instead of rebuilding it before fieldwork. |
| External readiness support | One-time for the initial gap review, recurring if repeated before renewals. Paid to an implementation partner or consultant under a written scope. | Maturity of the existing risk process and the number of systems and third parties in scope. | Ask for a fixed-scope readiness review with named deliverables, and confirm whether it covers the AI security requirements if they apply. |
| Independent assessor effort | Recurring per assessment cycle. Paid to an Authorized HITRUST External Assessor organization. | Number of risk management requirement statements tested, depth of sampling and the quality of evidence provided at fieldwork. | Prepare organized evidence before the fieldwork window so testing does not turn into document hunts. Confirm the fee basis in writing with the assessor. |
| Remediation of corrective action plans | One-time per finding, with possible recurring control work afterward. Paid as internal time and sometimes as external engineering. | Missing or late authorizations, unreviewed risks and undocumented risk acceptances, which are common causes of gaps in this domain. | Run a self-check against authorization and review records before the assessment so gaps surface while they are still cheap to fix. |
Who owns risk management, who prepares evidence and who issues the result
Your organization owns the controls in this domain. Only your leadership can decide which risks are acceptable, which systems may be authorized for use, and how much residual risk the business will carry. An assessor will ask who made those decisions, when, and on what basis, so the decisions must be made by people with the authority to make them and recorded in a way that can be produced on request.
- Risk decisions: Named owners accept, mitigate, transfer or avoid each risk and sign off the treatment plan.
- System authorization: Management formally approves new systems before they handle in-scope data and reviews those approvals on a set cycle.
- Risk review cadence: Leadership sets how often the risk register is reviewed and what triggers an early review.
- Exception approval: Someone accountable signs off each deviation from policy and sets an expiry date for it.
- Staff involvement: Security, IT and business owners contribute the facts behind each risk entry.
Before engaging any outside party, confirm internally who holds each of these decisions and that they can show a record of them.
An implementation partner such as DeployOpen prepares the systems, workflows and evidence that your team and the assessor will rely on. This work is preparation, not decision-making. The partner can help you build a risk register, design the authorization workflow, collect the records that show each control operating, and run a readiness review that surfaces gaps before the formal assessment begins. The partner does not accept risks on your behalf, does not write your risk appetite, and does not issue any report or certificate.
- Register and workflows: Build the risk register, authorization forms and review schedule in the tools your team will keep using.
- Evidence collection: Set up logging of approvals, review minutes and risk status changes so records exist for the assessment window.
- Readiness review: Test the process against the requirement statements in this domain and list the gaps.
- Remediation support: Help close gaps with configuration, documentation and training, with ownership left with your staff.
- Handover: Document how the process runs so it continues after the engagement ends.
Request a written scope that names each deliverable in this list before work starts.
Only an Authorized HITRUST External Assessor organization can perform a validated assessment submitted for certification, and HITRUST performs central quality assurance before it issues the report. The assessor tests whether the risk management process operates as documented, samples records across the assessment period, and scores each requirement statement. Its independence is the reason its result carries weight, so it cannot design the controls it then tests.
- Independent testing: The assessor samples authorizations and risk reviews and checks that they match the documented process.
- Scoring: Each requirement statement in the domain is scored and the domain result feeds the overall certification.
- Quality assurance: HITRUST reviews the submission centrally before any report is issued.
- Fieldwork window: Validated fieldwork runs for a limited period, so evidence must be ready before it starts.
- Line of independence: Advice on building the process is separate from the assessor's testing, and many organizations avoid having the same firm do both.
Confirm the assessor's Authorized status on HITRUST's public directory before signing, and ask how it handles preparation work for the same engagement.
Where risk management usually falls short and how to close it
Risk management under HITRUST is judged on whether decisions are made, owned and revisited, not on whether a risk register exists. The gaps below recur across assessments, and each one has a closure action the organization can run before fieldwork begins.
Systems go live before authorization
Many environments add services, tenants or data flows first and seek formal approval later, so the authorization record is dated after the system already handles in-scope data. HITRUST's 2025 Trust Report ranks a requirement for management to formally authorize new systems and review those authorizations among the most frequent corrective action plans. Close it by making written authorization a gate in change and provisioning workflows, and check that each in-scope system has an approval record dated before its first production use.
Risk registers that nobody reviews
A register that was populated once and never revisited shows assessors that risk decisions are not maintained. Assessors look for evidence of periodic review, changes in scope, and risks that were re-rated after incidents, audits or architecture changes. Close it by setting a review cadence in the policy, recording each review with attendees and changes, and tying register updates to change tickets and incident closures.
Treatment decisions without an owner
A risk marked as accepted, mitigated or transferred needs a named person who holds that decision and its budget. Without an owner, treatment plans stall and accepted risks drift past their original assumptions. Close it by recording a single accountable owner for every treatment decision, the rationale, the expiry or review date, and the compensating controls relied on, and confirm that owners sign off on residual risk.
Shared risk assumed to be handled by someone else
Cloud and SaaS providers often perform parts of risk management, but the organization still owns the risk for its own configuration, data and users. HITRUST's inheritance guidance notes that a provider does not perform risk management for the customer, even where some change management requirements sit in this domain. Close it by mapping which risk activities the provider covers, obtaining that evidence, and documenting the remaining activities as yours.
AI systems outside the risk process
Models, AI features in SaaS products and agent workflows often enter use through business teams rather than through the formal intake process. When an AI security certification is in scope, HITRUST places AI security requirement statements in this domain, so unregistered AI systems become assessment gaps. Close it by adding AI use to the system inventory and authorization gate, and assessing each system's data, access and failure modes before it reaches production.
Risk findings that never reach remediation
Risks identified in penetration tests, audits or incident reviews often stay in separate tools, so the register and the remediation tracker disagree. Assessors trace findings from source to treatment and closure, and gaps in that chain are easy to test. Close it by linking each finding to a register entry, a treatment owner and a due date, and by reviewing overdue items at a set management forum.
Questions buyers ask about risk management in HITRUST
How much effort does risk management take in a HITRUST assessment?
The effort depends on how many domain 17 requirement statements apply to your scope and how mature your current risk process is, so no fixed figure applies to every organization. The main drivers are whether you already have a documented risk assessment and treatment method, how many systems must be formally authorized before use, how consistently periodic reviews happen, and whether an AI security certification adds requirements. Domain 17 is one of 19 assessment domains, and the HITRUST 2025 Trust Report lists Risk Management as 9.8% of failing domains in 2024, tied for second. Ask any consultant to break the effort down by requirement statement and to state which evidence they assume already exists.
Can our own team handle risk management for HITRUST in-house?
Yes, the organization owns its controls and can build and run the risk process internally. The validated assessment itself, however, must be performed by an Authorized HITRUST External Assessor, and HITRUST performs central quality assurance before it issues reports. Internal teams usually find the hardest part is consistent evidence: every in-scope system needs a recorded management authorization before use, and those authorizations need periodic review. An implementation partner can prepare the process, documentation and evidence in your environment and support a readiness review, but it cannot issue the report or certification. Confirm the assessor's authorization status before signing anything.
Does inheriting controls from a cloud provider reduce domain 17 work?
Only in part. In HITRUST's Oracle Cloud Infrastructure inheritance example, risk management is treated as moderately inheritable because some change management requirements sit in this domain. The provider does not perform risk management for the customer, so the customer still owns its risk assessments, system authorizations and periodic reviews. Before relying on inherited results, request the provider's shared responsibility matrix, identify which requirement statements it covers, and confirm with your assessor exactly where the inheritance stops. The HITRUST inheritance blog post explains the example in more detail.
Does adding the HITRUST AI security certification add requirements to risk management?
Yes. HITRUST's AI Security Assessment help page places AI security requirement statements in domain 17, so adding that certification to an e1, i1 or r2 adds requirements to this domain. In practice, the risk assessment and system authorization process must cover the AI systems in scope, and the records must show that those systems were reviewed before use and on a recurring basis. Confirm the exact statements for your chosen assessment type in the current CSF version in MyCSF, because the count and wording change between versions. The AI Security Assessment help page is the natural starting point for scoping.
What evidence must our team supply for domain 17?
Your team must supply records that show the risk process runs and that decisions were acted on. The usual evidence set includes:
- A documented risk assessment and treatment method, with the current risk register
- Treatment plans with named owners, target dates and status updates
- Management authorization records for each in-scope system, dated before use
- Records of periodic risk reviews and any authorization renewals
- An inventory of AI systems in scope, if the AI security certification applies
Assessors test a sample of this evidence within a fieldwork window of at most 90 days, so records must be dated consistently across the period. Ask your assessor how they will select samples before you collect anything.
How do scores in domain 17 decide whether an assessment passes?
Each domain is scored separately, so domain 17 must clear its threshold on its own. For e1 and i1, the core requirement statements in each domain must average at least 83. For r2, each domain must average at least 62 across all its requirement statements. The authorization requirement, which asks management to formally authorize new systems and review those authorizations, appears eighth among the most frequent corrective action plans in the HITRUST 2025 Trust Report. A weak score here can therefore fail a domain even when the rest of the program is sound. Run an internal scoring exercise against the thresholds before fieldwork starts.
Which open-source tools can help evidence risk management?
CISO Assistant, licensed under AGPL-3.0-only, is an open-source option for managing risk and compliance work. Its README states that it ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and that it runs audits and compliance assessments with automatic mapping between frameworks. Confirm two points before adopting it: whether it covers HITRUST CSF requirement text, which is proprietary and not listed among its supported frameworks in the supplied README, and whether the AGPL-3.0-only license fits how your organization uses and distributes it. Treat the tool as a way to hold risk registers, authorizations and review records, and check its output with your assessor. The CISO Assistant README describes its current feature set.
How open-source GRC tooling can hold risk management evidence
CISO Assistant is a self-hosted, open-source governance, risk and compliance tool licensed under AGPL-3.0-only, and it can hold the records that show a HITRUST 17 Risk Management program is running. It ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and it can run audits and compliance assessments with automatic mapping between frameworks. For a HITRUST program, the practical use is as a system of record for the risk register, the risk treatment decisions and the authorization records that the domain depends on. Its shipped frameworks are a starting point for your own requirement set, not a substitute for the HITRUST CSF, which the tool does not license or certify against. Confirm with the vendor whether a HITRUST framework is available in your deployment before you plan around it.
Structure the tool around the decisions a HITRUST assessor will sample. Record each system in scope with its owner, data classification and intended use, then link a risk entry to that system, its treatment decision, the accepting manager and the review date. Keep the formal authorization as its own object with the approver, the conditions attached and the evidence reviewed, such as a completed risk assessment and a signed change request. Attach the supporting files, meeting minutes and sign-off emails to each record rather than storing them in a separate folder, so a sample can be traced from the system to the decision in one step. Ask your assessor, before you build this, how they expect authorization records to be presented and whether they accept exports from a tool like this as evidence.
Confirm three things before committing. First, the AGPL-3.0-only license requires you to review your obligations if you modify the software and make it available to users over a network, so check this with your legal team against your own deployment. Second, test whether the tool's workflow matches your approval chain, including any tiered sign-off, delegation and periodic review reminders that your policy requires. Third, decide who operates the instance, who holds administrator rights and how backups and access logs are kept, because the tool's records are only as credible as the controls around them. Any help you bring in to configure the tool prepares evidence for your assessment, while the independent assessor, not the tool or the implementer, decides whether your risk management meets the requirements.
