How HITRUST scoring works and what it means for your certification
Each HITRUST requirement statement is scored from strength and coverage on a five-level rating, and certification depends on domain averages rather than any single requirement. The e1 and i1 need the core statements in each domain to average at least 83, and the r2 needs each domain to average at least 62. If a customer or contract now requires HITRUST, the practical question is whether your controls will clear those averages in every one of the 19 assessment domains, and that answer differs by organization because it depends on your scope, how evenly each control applies across that scope, and what exceptions an assessor records. The roles matter here. Your organization owns its controls and decides what is in scope. An implementation partner can help prepare systems, configurations and evidence, but it does not score anything. Only an authorized HITRUST External Assessor performs the validated assessment, and HITRUST performs central quality assurance before it issues the report and any certification. Ask any partner to say plainly which of those steps it performs and which it does not.
Before you commit budget, run a scoring dry run against the scope you expect to assess. For each requirement, ask whether the control is consistently in place across every business unit, data center and application in scope. Where coverage is partial, record the gap and the reason for it, because uneven coverage is averaged or weighted against scope items and that arithmetic can pull a domain below its threshold even when most of the work is done. Ask the assessor, early and in writing, how it will weight scope items and which exceptions it expects to reflect in scoring, and agree the scoring approach with management before fieldwork starts. Exceptions reduce scores, usually by lowering strength or coverage, so an unresolved finding can cost more than its size suggests. Use the HITRUST Assessment Handbook to check the current scoring rules for your assessment type, and confirm with your External Assessor which version of the Handbook and the CSF applies to your submission.
How the five ratings build a requirement statement score
HITRUST's Control Maturity Scoring Rubric turns each assessed maturity level into one of five ratings. Two judgments sit behind every rating, strength and coverage, and together they produce the requirement statement score that domain averages are built from.
Non-Compliant rating
This rating applies when the requirement is absent or fails to operate in a way that addresses the risk. The assessor finds no usable strength or coverage for the statement, so the score contributes nothing toward the domain. Before a validated assessment, check whether a control exists on paper but is not performed, because assessors score operation, not intent. Confirm with your assessor how a missing control on one scope item is recorded.
Somewhat and Partially ratings
Somewhat means the control exists but is weak in strength or narrow in coverage, while Partially means it is more developed but still leaves material gaps. Both ratings are where many scores fall short, because a policy that is written but inconsistently applied sits between them. Review each statement for whether the control is performed consistently and across all in-scope items, not only where it was easiest to implement.
Mostly and Fully Compliant ratings
Mostly Compliant means the control is strong and broadly applied with minor exceptions, and Fully Compliant means it is strong and applied across the full scope without material exceptions. Assessors look for evidence that the control operates over the assessment period, not only on the day of testing. Ask your assessor which evidence they expect for the higher ratings before fieldwork begins.
Strength and coverage judgments
Strength asks how well the control is designed and performed, and coverage asks how much of the in-scope population it reaches. The rating combines both, so a strong control covering only part of the environment can still drop a statement to a lower rating. Map each requirement to the systems, business units or data centers it must reach, then check each one has evidence.
Exceptions that lower ratings
Each exception an assessor finds must be reflected in scoring, typically by lowering strength or coverage, and scoring changes are discussed with management before they are final. Exceptions therefore move the rating, not only the narrative. Track known deviations internally, document how each one is handled, and agree with the assessor how a single exception is weighed against the statement as a whole.
From rating to statement score
The five ratings feed a calculation that produces the requirement statement score, which is then averaged into the domain score that is compared against certification thresholds. Because the rating scale is ordinal, a small change in one statement can move the domain average meaningfully. Ask your assessor to show how each rating converts into the statement score so you can check the arithmetic.
How uneven coverage across scope items changes the score
Uneven coverage happens when a requirement applies to some business units, data centers or applications but not to all of them. HITRUST's scoring guidance lets the assessor handle this in one of two ways: average the score per scope item, or weight the items with a documented rationale. In the Handbook's example, a policy that covers three of four business units scores 75 under averaging, because three units are fully covered and one is not covered at all. The point for you is that the uncovered unit pulls the score down in proportion to its share of the scope, so a gap in one unit can still matter a great deal when the domain average is close to its threshold.
Weighting changes that arithmetic. Instead of giving every item equal influence, the assessor assigns each item a weight based on a documented reason, such as the number of applications hosted at each data center. A large data center with most of the regulated workloads can then carry more of the score than a small office. Weighting is only defensible if the rationale is written down, uses data you can produce from a system of record, and reflects the actual risk. Choosing weights because they lift a score is the fastest way to lose the assessor's confidence in the rest of the work.
Before fieldwork starts, agree the method and the rationale for each uneven requirement in writing, and confirm them with your Authorized HITRUST External Assessor. Ask which scope items the assessor expects to average, which it expects to weight, and what inventory or data will support each weight. Then check the scope list against your scoping decisions so that no unit is quietly excluded. Scoring changes are discussed with your management, so raise any disagreement during fieldwork rather than after the draft results arrive.
How exceptions lower a score and who agrees the change
This sequence turns each exception an assessor finds into a documented scoring change that the entity's management has discussed and accepted before the result is final. The entity then knows which scores moved, why, and whether any domain now sits close to its threshold.
Assessor records the exception
During fieldwork, the external assessor compares the evidence the entity provided with what each requirement statement requires and records every gap as an exception. The exception log names the requirement statement, the scope item affected and the evidence that was missing or contradicted. Your team's check at this stage is to confirm that each exception describes a fact you can verify, such as a missing review record or a control that did not operate for part of the period. The step is complete when every exception has a reference to a specific requirement and a specific piece of evidence.
Assessor decides which scoring element moves
The assessor applies the Control Maturity Scoring Rubric to each affected requirement and decides whether the exception lowers strength, coverage or both. Strength reflects how well the control is designed and operated, while coverage reflects how much of the in-scope population it reaches. Lowering a rating in one element can change the requirement statement score without touching the other element. The output is a proposed rating per affected requirement, with a short rationale tied to the exception.
Recalculate the requirement and domain scores
With the revised ratings, the assessor recalculates each affected requirement statement score and then the domain averages that include it. If the control applies unevenly across scope items, the per-item averaging or documented weighting described earlier in the rubric is applied to the revised figures. Your team should rerun its own calculation from the proposed ratings so that any arithmetic difference is found before the discussion, not after. The output is a draft scoring table showing before and after values for each affected domain.
Present the proposed changes to management
The assessor discusses the proposed rating changes with the entity's management, typically the person accountable for the assessment and the control owners for the affected domains. The conversation covers each exception, the evidence that supports it, and the reason a rating moved. Bring the control owner who can explain what happened, and bring any evidence that was not in the original submission so it can be considered on its merits. The output is a list of items the entity accepts, items it disputes, and items that need more evidence.
Resolve disputed scoring with evidence
Where management disagrees with a proposed change, the disagreement should be resolved with specific evidence, not general argument. The assessor reviews any new material, explains whether it changes the rating, and records the outcome for each disputed item. Your team should expect that some disagreements cannot be resolved and should plan to accept the assessor's rating or address the gap through the corrective action process described elsewhere in this group. The output is a final, documented position on every disputed exception.
Agree the final scores with management
Once the disputed items are settled, the assessor and management agree the final scoring for every requirement statement and domain. Agreement is recorded so that both parties hold the same figures before the result moves into review. Your check at this point is to confirm that each domain average you care about, including the thresholds for your assessment type, is shown in the agreed scoring. The output is a signed-off scoring position that is the basis for the next step.
Submit scoring for HITRUST quality review
The agreed scoring goes into the validated assessment submission, and HITRUST performs its central quality assurance before any report is issued. HITRUST reviews the work of the assessor, so the scores in the submission must match what was agreed with management. Your team should keep its copy of the exception log, the rating rationales and the agreement record, since these support questions from HITRUST and from relying parties later. The output is a quality-reviewed result that determines whether the certification thresholds were met.
Which thresholds decide certification for e1, i1, r2 and the NIST CSF report
This table compares the maturity level each assessment scores, the domain average needed to certify and what a missed threshold produces. Read each row as a separate gate: an assessment can certify on its HITRUST thresholds while still falling short of the NIST CSF report threshold.
| Assessment | Maturity level scored | Domain threshold to certify | Outcome if the threshold is missed |
|---|---|---|---|
| e1 | Implemented | Core statements in each domain average at least 83 | Validated-only report stating thresholds were not met, with no certification letter |
| i1 | Implemented | Core statements in each domain average at least 83 | Validated-only report stating thresholds were not met, with no certification letter |
| r2 | Policy, procedure and implementation | Each domain averages at least 62 | Validated-only report stating thresholds were not met, with no certification letter |
| NIST CSF report (added to an r2) | Policy, procedure and implementation across NIST-mapped requirements | Average of at least 70 on each NIST core function and category | No NIST Cybersecurity Framework certification report is issued |
| Scoring unit | Requirement statement score built from strength and coverage | Averages are taken per domain, so one weak domain can block certification | Confirm with your assessor how uneven scope items are averaged or weighted |
| Who issues the outcome | Authorized HITRUST External Assessor performs the assessment | HITRUST performs central quality assurance before reports issue | Independent assessor and HITRUST issue results, not the implementation partner |
Why the NIST CSF report needs its own score of 70
An r2 assessment produces a NIST Cybersecurity Framework certification report only when the average score of the NIST-mapped HITRUST requirements reaches at least 70 on each core function and on each category. This is a separate test from the domain thresholds. An r2 can clear every domain average and still not earn the NIST report, and a low score on one NIST function can block it even when the overall result looks strong. Plan for both tests from the start, because the NIST report is not a by-product of passing the certification.
The NIST-mapped set is defined by the CSF version in use, not by the domain structure you see in your scorecard. HITRUST refreshes its mappings between versions, and the v11.9.0 release refreshed its NIST SP 800-53 Rev. 5.2.0 mapping, so a requirement that counted toward a NIST category in an earlier version may not count the same way now. Before scoping, confirm the current mapping in MyCSF and ask your External Assessor to show which requirement statements feed each NIST function and category in your assessment. Get that list in writing so you can compute the category averages yourself during readiness.
Use the mapping to find weak spots early. Build a simple worksheet that groups your scored requirements by NIST function and category, then check each average against 70 while your controls are still changing. A category that sits just below the line is usually held down by one or two requirements with partial coverage across scope items, so the fix is often narrow evidence work rather than new controls. Because a NIST report depends on the same scores, any corrective action plan that lowers a NIST-mapped requirement affects this result as well as the domain averages.
What moves a domain average up or down
A domain average is built from many requirement statements, each scored across scope items, sampled evidence and agreed scoring decisions. The factors below are the ones an organization can shape before fieldwork starts, and most of them are settled in writing well before the assessor arrives.
Scope selection and N/A decisions
The scope determines which systems, locations and business units are scored at all. Every requirement marked not applicable must be justified, and an unsupported N/A removes a requirement that would otherwise count toward the average. Record the reason for each exclusion and confirm with your assessor that the boundary matches how the organization actually operates. Changes made late in the process are harder to defend.
Evidence of consistent operation
Assessors score whether a control runs as described over the period tested, not whether a document exists. A policy that is approved but not followed will score lower than a procedure with dated records showing it runs. Before the assessment, check that recurring activities such as access reviews, patching and log reviews have records for each cycle in the window.
Coverage across in-scope systems and locations
A requirement that applies to four business units or several data centers is scored by how many of them actually meet it. If a control covers three of four units, the average reflects that gap, and the uncovered unit is often the one the assessor samples. Inventory each in-scope system and location, then confirm the control is present in every one before scoring begins.
Exceptions found during sampling
Each exception the assessor identifies in sampled items is reflected in scoring, typically by lowering strength or coverage. A single missed approval in a sample can move a score more than expected, so sample readiness matters. Run your own sample pull against the requirement wording and fix or document exceptions before fieldwork, since an exception found by the assessor is scored as found.
Weighting method agreed in advance
When a requirement applies unevenly, scores can be averaged per scope item or weighted by a documented rationale, such as the number of applications at each data center. The method changes the result, so agree it with the assessor and record the rationale in writing before fieldwork. Scoring changes are discussed with management, so raise any disagreement during fieldwork rather than after the report draft.
How scoring fits into the assessment from start to report
This sequence shows how a requirement statement moves from preparation through validated fieldwork, agreed scoring and HITRUST quality assurance to a certification or a validated-only report. Each phase produces a checkpoint the organization can verify before moving on.
Define scope and complete readiness work
The organization decides which systems, facilities and business units fall inside the assessment scope, then works with its implementation partner to check each requirement statement against current controls and evidence. The organization owns every control and makes the final decisions on scope. The step closes when the scope is written down, the assessment type is confirmed (e1, i1 or r2) and the gaps the team has found are logged with owners. Ask the partner to show how each scope item maps to the requirement statements it must meet.
Select an authorized External Assessor
Only Authorized HITRUST External Assessor organizations may perform validated assessments that are submitted for certification. The organization engages one through a written agreement that covers fees, scope and the assessor's deliverables. An implementation partner can prepare systems and evidence, but it cannot issue the assessor's findings or scores. The step is complete when the assessor is confirmed as authorized and the engagement letter names the assessment type and scope.
Run validated fieldwork within the 90-day window
The assessor tests each requirement statement against the evidence the organization provides, including interviews, documents, configurations and samples. The validated assessment fieldwork window is at most 90 days for e1, i1 and r2, so evidence must be ready and organized before fieldwork begins. Where a control applies unevenly across scope items, the assessor records how coverage differs. The step closes when fieldwork ends and the assessor has a complete set of test results for every requirement statement in scope.
Score strength and coverage for each statement
The assessor rates each requirement statement against HITRUST's Control Maturity Scoring Rubric, looking at strength and coverage to reach one of five ratings. Uneven coverage is either averaged across scope items or weighted with a documented rationale. Each exception the assessor finds is reflected in the score, usually by lowering strength or coverage. The step ends with a scored draft for every statement, and the team can see which exceptions drove each lower score.
Agree scoring changes with management
Before the scores are finalized, the assessor discusses scoring changes with the organization's management. The organization can challenge a finding by providing additional evidence or clarifying scope, and the assessor decides whether the evidence changes the rating. The step is complete when management has reviewed the scored results and the open points are either resolved or recorded. Ask for a written list of every score that changed after the initial draft and the reason for each change.
Complete HITRUST central quality assurance
HITRUST reviews the submitted assessment centrally before any report is issued. This check confirms that the scoring follows HITRUST methodology and that the documentation supports the results. Questions from HITRUST may send the assessor back to clarify particular statements. The step closes when HITRUST has finished its quality review and is ready to issue the report.
Receive the certification or validated-only report
If the domain averages and other thresholds are met, the organization receives a report and certification letter for its assessment type. If a threshold is not met, HITRUST issues a validated-only report that states the thresholds were not met and includes no certification letter. The organization then decides how to respond, including whether to plan corrective actions. The step is complete when the outcome is recorded in MyCSF and the organization has read the report and its scoring summary.
How to check your own scores before the assessor does
A draft score is only useful if you test it the way an External Assessor will. The checks below cover the rubric inputs, the domain thresholds, coverage across scope items and the exceptions that move a score. Together they show where a draft is likely to fall short before fieldwork starts.
Score each requirement against the rubric
Rate every requirement statement on strength and coverage, then map the result to one of the five ratings: Non-Compliant, Somewhat, Partially, Mostly or Fully Compliant. Use the same rating scale the assessor will use, and record the evidence behind each rating. A rating you cannot tie to a specific artifact is the first thing to revisit. Score the evidence you hold today, not the controls you plan to add.
Check domain averages against thresholds
Calculate each domain's average for the scoring basis of your assessment type. The e1 and i1 score the Implemented level, with core statements needing to average at least 83 per domain. The r2 scores policy, procedure and implementation, with each domain needing an average of at least 62. Flag any domain within a few points of the line, since one exception can move it below.
Test coverage across scope items
Where a requirement applies to some business units, data centers or applications and not others, check coverage item by item. An illustrative case: a policy in place for three of four business units would score 75 under per-item averaging. Confirm the scope list is complete before you average, because a missing item inflates the domain.
Document the weighting rationale
If you weight scope items rather than averaging them, write down the basis, such as application counts per data center, and keep it with the scoring workpapers. An unexplained weighting is easy for an assessor to reject. Agree the basis with the entity's management before scoring is finalized, since scoring changes are discussed and agreed with management.
Log known exceptions and likely effects
Keep a register of every exception you already know about, including the requirement, the scope item affected and the expected drop in strength or coverage. Assessors reduce scores for each exception they find, so an exception you have already quantified is easier to discuss than one they surface. Note which exceptions could push a domain below its threshold.
Confirm the scoring trail is reproducible
Keep each rating, its evidence reference and the reviewer's name in one place so another person can reproduce the domain average. Re-score a sample of requirements after a few days without looking at the first result, then compare. Large differences point to unclear evidence or inconsistent judgment, which are the causes most worth fixing before the assessor's fieldwork window opens.
Who scores the assessment and who prepares the evidence
The organization owns its controls, and the HITRUST score is a statement about what it actually operates. It decides the assessment scope, which systems, facilities, business units and third parties sit inside the boundary. It also decides how requirement statements apply to its environment, and it is the party that agrees any scoring changes an assessor proposes during fieldwork. Certification is granted to the organization, so accountability for the result stays with its leadership, not with a consultant or tool vendor.
- Scope decisions: Choose the assessment type and the systems, locations and business units inside scope, and document why others are excluded.
- Control ownership: Name an accountable owner for each control area and make sure the control operates day to day, not only on paper.
- Scoring agreement: Review each exception and proposed score change with the assessor, and agree or challenge it on the basis of evidence.
- Uneven coverage: Decide with the assessor whether a requirement is averaged across scope items or weighted, and record the rationale.
- Ongoing operation: Keep controls running between assessments, since scores reflect the period the assessor tests.
Before fieldwork, confirm internally who will answer assessor questions and who signs off on scope and scoring discussions.
An implementation partner such as DeployOpen helps the organization prepare its systems, controls and evidence before the assessor arrives. Work can include configuring logging, access reviews, backup and vulnerability tooling inside the client's own infrastructure, then collecting and documenting the output so it is easy to test. A partner can also write down the rationale behind how a requirement was implemented, so the organization can explain it accurately during scoring. The partner does not score requirement statements, does not decide maturity ratings, and does not issue or influence the certification outcome.
- System preparation: Deploy or harden the platforms that produce evidence, such as log pipelines, identity and configuration tooling, inside the client's own environment.
- Evidence packaging: Organize configuration exports, review records, tickets and test results so they map to the relevant requirement statements.
- Scoring rationale documents: Write clear, factual notes on how each control works and where coverage is partial, for the organization to share with the assessor.
- Gap identification: Flag controls that look weak before fieldwork so the organization can fix them or plan a corrective response.
- Limits of the role: Never present partner preparation as an assessment result, and never sign or certify a score.
Ask any partner to state in writing which of these tasks it performs and which it leaves to the assessor and HITRUST.
Only an Authorized HITRUST External Assessor organization may perform a validated assessment submitted for certification. The assessor tests the controls, performs fieldwork within the permitted window, applies the Control Maturity Scoring Rubric, and proposes scores that reflect each exception it finds. HITRUST then performs central quality assurance before any report is issued. A certification letter is issued only when the thresholds are met; otherwise the outcome is a validated-only report.
- Independent testing: The assessor samples evidence, interviews staff and observes controls, and it decides whether each requirement is met.
- Scoring: The assessor assigns strength and coverage ratings from which the requirement statement score is computed.
- Fieldwork window: Validated assessment fieldwork for e1, i1 and r2 is limited to at most 90 days, so evidence must be ready before it starts.
- Quality assurance: HITRUST reviews the submission centrally before issuing the report and any certification.
- Outcome: The organization receives a certification or a validated-only report, depending on whether thresholds are met.
Confirm the assessor's authorization status on HITRUST's Find an External Assessor page before signing an engagement letter.
Questions buyers ask about HITRUST scoring
Can a domain still pass if one scope item is weak?
Yes, but only if the domain's average still clears the threshold. HITRUST scores a requirement across the scope items it applies to, so a strong result on most items can offset a weak one. The e1 and i1 need each domain's core statements to average at least 83, and the r2 needs each domain to average at least 62 on policy, procedure and implementation maturity. A weak scope item can still sink a domain, though, because every exception the assessor finds must be reflected in scoring by lowering strength or coverage. Check each domain's average against the threshold for your assessment type, not just the overall result.
What is the difference between averaging and weighting scope items?
Averaging gives each scope item equal weight, while weighting gives items different influence based on a documented reason. HITRUST's handbook gives an example of averaging: a policy that covers three of four business units scores 75. Weighting is used when items differ in size or risk, such as the number of applications hosted at each data center. Weighting needs a documented rationale that the assessor can review and that management agrees to. Choose the method before fieldwork starts, because changing it after a low result looks like score shopping.
Can we calculate our own HITRUST scores before the assessment?
You can and should estimate them, but your estimate is not a HITRUST score. Only an Authorized HITRUST External Assessor organization performs the validated assessment, and HITRUST performs central quality assurance before reports are issued. Internally, you can apply the rubric to each requirement statement, rating strength and coverage on the five-point scale from Non-Compliant to Fully Compliant, then average by domain and compare the result to the thresholds. Use the handbook's rubric definitions and document your reasoning so the assessor can test it. Treat any internal number as a readiness signal, since the assessor's view of evidence and exceptions will decide the final score.
How long does the fieldwork for a validated assessment take?
The assessor's validated assessment fieldwork window is at most 90 days for e1, i1 and r2. That window covers the assessor's testing and evidence review, not the months of preparation that usually come before it. Preparation time depends on how mature your controls are, how many scope items you have, and how much evidence must be collected over a period. Ask the assessor to confirm the planned fieldwork dates in writing, and ask how they will handle evidence requests that come back incomplete, since delays there count against the window.
What must our team provide to the assessor?
Your team must provide the systems, documented policies and procedures, implementation evidence and access the assessor needs to test each requirement statement. In practice that means a defined scope, a list of scope items and their owners, system and data flow descriptions, and evidence that covers the period under review. You also need named people who can answer questions, explain exceptions and agree on scoring changes with the assessor. An implementation partner can help prepare systems and evidence, but it cannot issue scores or reports. Confirm with your assessor exactly which artifacts and sampling approach they will use before you start collecting.
What happens after a validated-only result?
A validated-only result means the assessment did not meet the certification thresholds. HITRUST issues a validated-only report that states the thresholds were not met and includes no certification letter. The report does not certify you, so customers and regulators reading it will see that the threshold was missed. Your next steps are to review which domains fell short, decide how to remediate the underlying gaps, and plan a new assessment once the work is complete. Ask your assessor to walk you through the exceptions behind each low domain score before you decide on remediation or a corrective action plan.
Does the NIST CSF report threshold apply to every r2?
No, it applies only to an r2 that is assessed for the NIST Cybersecurity Framework report. An r2 yields a NIST Cybersecurity Framework certification report only if the average score of NIST-mapped HITRUST requirements is at least 70 on each core function and category. That means a strong overall r2 can still fail to produce the NIST report if one function or category falls below 70. If you need the NIST report, check the NIST-mapped averages early, since they can be lower than your domain averages. Confirm the scope and mapping details with your assessor before fieldwork begins.
Does DeployOpen score our HITRUST assessment?
No. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and it does not assign HITRUST scores. The scoring decision belongs to an Authorized HITRUST External Assessor, with HITRUST performing quality assurance before reports are issued. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.
How DeployOpen prepares scoring evidence ahead of the assessment
DeployOpen does not score, issue reports or certify. Scoring under the HITRUST rubric is performed by an Authorized HITRUST External Assessor during the validated assessment, and HITRUST performs its own quality assurance before any report is issued. DeployOpen's role is to prepare the systems and evidence that an assessor will score. Engagements start with a fixed-scope agreement, written before work begins, that names the assessment type, the in-scope platforms, the business units and data centers covered, and the domains the client wants supported. Pricing follows from that written scope, so the first conversation with DeployOpen should be about what the scope includes and excludes.
Once scope is agreed, DeployOpen implements and hardens the self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For each domain, the team documents how each control operates, who owns it, how often it runs and where its output is stored. Where a requirement applies unevenly across scope items, such as a logging or access review that covers some applications but not others, the documentation records which items are covered, so the client can make the averaging or weighting decision with the assessor. Any exception found during preparation is logged with its owner and remediation status, because an assessor will reflect every exception in the score.
The handover is an evidence package organized by domain: control descriptions, configuration baselines, sample records, review logs and the ownership map. The client's own compliance staff should check that each piece matches what the assessor will request, and that operation over the assessment window can be shown from the records. Clients should confirm with DeployOpen in writing which evidence is produced, which remains their responsibility, and how the package is kept current. Preparation improves readiness, but it does not guarantee a particular score, and the assessor's findings govern the outcome.
