When can you mark a HITRUST requirement N/A?
An N/A needs a rationale that covers every system, facility and third party in scope, and an activity simply not occurring is never a valid reason. If a requirement looks irrelevant to your environment, the question to answer is not whether the control is needed today but whether every in-scope component is excluded for a documented reason. Readiness leads often find that a requirement seems idle because the activity has not happened yet, such as a process that has never been triggered. HITRUST does not accept that as an N/A basis, so the rationale has to address why the requirement does not apply to the scoped environment, not why it has not been exercised. The answer also depends on the assessment type (e1, i1 or r2), the scope letter and whether a third party performs the requirement, so check all three before you decide.
The organization owns the N/A decision. It is accountable to its assessor and to the relying parties who read the eventual report, so the rationale should come from the people who run the systems. An implementation partner can help draft the rationale, map each in-scope system, facility and third party to the requirement, and assemble the supporting evidence. Only the assessor and HITRUST quality assurance can decide whether an N/A stands. Confirm early with your External Assessor how they expect rationales to be written, because a weak justification found in fieldwork is far more costly to fix than one drafted during readiness.
Before you mark anything N/A, run a short check against the rules in HITRUST's Assessment Handbook. Confirm whether a third party is performing the requirement, since that is only a valid reason under a documented e1 or i1 carve-out, and never for an r2. Look for mixed applicability, where a requirement is marked N/A for a service that is scored elsewhere in the same assessment, and check whether any monitoring requirement is one that typically cannot be marked N/A. Record each decision with its rationale in MyCSF so the reasoning is visible to the assessor from the start, and review the HITRUST Assessment Handbook for the exact wording of these rules before the rationale is finalized.
Which route fits a requirement you want to exclude?
This table compares the four routes a buyer may consider when a HITRUST requirement does not fit the environment as written. Read each row against your own scope: the route that fits depends on whether the requirement is not applicable, owned by a third party, driven by your r2 factors, or applicable but unmet.
| Route | When it fits | What must be documented | What QA will check |
|---|---|---|---|
| N/A with rationale | The requirement covers a system, facility or third party that is genuinely outside scope, and no in-scope component performs the activity | A rationale covering every system, facility and third party in scope, explaining why the requirement does not apply | Whether the rationale addresses all in-scope components, and whether non-occurrence or third-party performance is cited as the reason |
| e1 or i1 third-party carve-out with N/A | A service provider performs the requirement and the provider fully owns it, in an e1 or i1 only | Documented third-party responsibilities, removal of the provider from scoring, and an N/A rationale for each requirement it fully owns | That the provider is removed from scoring entirely and that no in-scope requirement is left unscored because of the carve-out |
| r2 tailoring through the scoping questionnaire | The requirement falls outside the organization, data, geography, technology or compliance factors you answer in MyCSF | A written rationale for every factor answered No, reflected in the tailored requirement statements | Whether factor answers are consistent with the scope and whether each No answer carries a written rationale |
| r2 service provider treatment | A service provider performs the requirement in an r2 assessment | Service provider responsibilities must stay in scope; they cannot be carved out of an r2 | Carve-outs of service providers are not accepted in an r2, so the requirement remains scored under the assessment |
| Alternate control | The requirement applies but cannot be implemented as written, and a compensating control addresses the same risk | A compensating control description and a risk analysis, submitted ahead of fieldwork | Whether the compensating control reduces the same risk and whether the Alternate Controls Committee approves it |
| Corrective action plan | The requirement applies, is not met at assessment, and a remediation plan is more realistic than an exclusion | A documented plan with owners, actions and dates tied to the gap | Whether the gap is recorded honestly in scoring, since an exclusion cannot be used to hide a requirement that applies |
Why HITRUST QA rejects an N/A rationale
HITRUST QA reviews every N/A rationale against the same test: does the reason explain why the requirement cannot apply to any system, facility or third party in scope? The five patterns below account for most rejections, and each one can be checked before submission.
Third party cited as the only reason
A rationale that says a vendor performs the requirement is not a valid reason on its own. In an e1 or i1, a third party can only support N/A under a documented carve-out, where its responsibilities are written down, it is removed from scoring entirely, and the requirements it fully owns are marked N/A with a rationale. In an r2, third parties cannot be carved out at all. Before submitting, confirm that every third party cited has a documented carve-out or that the requirement remains in scope.
Activity that did not occur
Saying an activity never happened, such as no data was transferred or no incidents occurred, is never a valid reason for N/A. The requirement describes what the organization must do, and a quiet year does not remove the obligation. Reviewers expect the control to exist and be testable. Before submitting, rewrite any rationale that depends on absence of activity so it explains why the requirement cannot apply to the scope itself.
Rationale that misses part of the scope
A rationale must cover every system, facility and third party in the assessment scope. A reason that is true for the primary application but silent on a secondary component, a data center or an endpoint population leaves a gap that QA will flag. Before submitting, list each scope component from the scope letter and confirm the rationale addresses each one by name or by a clearly defined group.
Mixed applicability across scope
Mixed applicability occurs when the same service is marked N/A for one requirement but is scored elsewhere in the same assessment. HITRUST treats this inconsistency as a defect because the organization is claiming a service is both out of scope and in scope. Before submitting, search the assessment for every service marked N/A and confirm none of them is scored in another domain or requirement.
Monitoring requirements marked N/A
Certain monitoring requirements typically can never be marked N/A, because they test whether the organization sees and responds to events in its environment. Marking them N/A usually signals that the scope or the requirement was misread. Before submitting, check each N/A monitoring requirement against the HITRUST Assessment Handbook guidance and confirm that a reviewer would accept the rationale as a true exclusion, not an avoidance of work.
How third-party carve-outs change the N/A decision for e1 and i1
In an e1 or i1, a third party can be carved out of the assessment only when three conditions hold: its responsibilities are documented, it is removed from scoring entirely, and any requirement it fully owns is marked N/A with a rationale. The order matters. Marking a requirement N/A because a vendor performs it is not a valid reason on its own, so the carve-out itself has to be documented and settled before any individual requirement is touched. Once the third party is out of scope for scoring, the requirements it fully owns can be closed as N/A, and each rationale should point to the carve-out record rather than restate the vendor's controls.
The r2 works differently, and this is where teams most often get caught. An r2 does not accept carve-outs of service providers at all. A third party that was carved out in an earlier e1 or i1 therefore cannot simply be carved out again when the organization moves up to an r2. The same vendor has to be handled through the r2's own mechanisms, such as inheritance or scoped controls, and each requirement touching that vendor must be answered on its merits. Before choosing an assessment level, the reader should map every third party that currently sits outside scoring and decide which of them will still be needed in an r2 and how their results will be reflected.
Confirm with your assessor how a carved-out third party changes the wording of each N/A rationale, including which documented responsibilities must be cited, how the boundary is described, and whether the vendor's name appears in the rationale. Ask whether the assessor expects a separate carve-out record or a single statement covering all carved-out parties, and whether your existing evidence for the vendor relationship, such as contract terms or review records, will be accepted. Raise these questions early, because QA will read each rationale against the carve-out decision, and a rationale that describes a third party the scope has already excluded is a common source of rework.
What to do in three common N/A situations
Mixed applicability arises when a requirement statement is marked N/A for one service while that same service is scored under the same or another requirement elsewhere in the assessment. The assessor tests whether the N/A rationale holds across every system, facility and third party in scope, not just the component that prompted the question. If the service is in scope for one requirement, its N/A marking on another requirement is inconsistent, and HITRUST flags it.
- Check the scope consistency: Confirm the service is either in scope or out of scope everywhere. A service cannot be scored in one domain and treated as absent in another.
- Document the rationale per service: Write why the requirement does not apply to that specific system, facility or third party, using its actual function.
- Confirm carve-out status: In an e1 or i1, a third party removed from scoring entirely may have fully owned requirements marked N/A. In an r2, third-party carve-outs are not accepted.
- Trace the dependencies: Map which requirements reference the service and confirm each one is scored or justified separately.
- Ask the assessor early: Raise the question in readiness review so the marking is settled before fieldwork.
Before submission, check that every N/A marking for a shared service matches its scope entry and its scoring elsewhere in MyCSF.
Some requirements typically cannot be marked N/A regardless of how the environment is built. These are usually monitoring, logging and detection requirements, because the organization must be able to see activity in every in-scope system. Claiming that a system is too small, too new or too simple to need monitoring is rarely accepted, since the assessor tests whether the organization can detect and review events for every component that handles the covered data.
- Expect monitoring to stay in scope: Logging, log review and security event monitoring usually apply to all in-scope systems, including those managed by a third party.
- Separate the control from the tool: If a service is outsourced, the requirement still needs evidence that events are collected and reviewed, even if a provider performs the work.
- Avoid tool-based exclusions: A rationale that a tool is not deployed is not a valid N/A reason when the underlying activity still occurs.
- Use the handbook list: Check the handbook guidance for which requirements typically cannot be N/A, rather than relying on a general sense of applicability.
- Plan the evidence: Gather log samples, review records and alert tickets from each in-scope component.
If a monitoring requirement appears N/A in your draft, treat it as a gap to close, not a marking to defend.
Non-occurrence is the argument that an activity has not happened, so the requirement does not apply. For example, an organization may have no incidents requiring a particular response procedure during the period. HITRUST does not accept that reason. A control that depends on a trigger still needs to exist, be documented and be ready to operate, so the assessor can test the design and any evidence that exists.
- Separate design from occurrence: The procedure must exist and be approved even if it has never been run.
- Test with what exists: Where no event has occurred, the assessor may look at exercises, tabletop records or the trigger logic instead.
- Use zero-occurrence rules: Check how HITRUST handles controls with no population before assuming no testing is needed.
- Do not mark N/A for a missing process: If the response plan is absent, the correct next step is to build it, not to mark the requirement N/A.
- Record the date of the last trigger: State when the activity last occurred and how the procedure would apply.
When the answer is no, the usual next step is to implement and document the control, then rely on incubation timing, or to use a corrective action plan or an alternate control where the requirement cannot be met as written.
How to build and submit an N/A rationale in MyCSF
This sequence takes a requirement statement you believe does not apply and turns it into a rationale that covers every system, facility and third party in scope, passes MyCSF quality checks, and holds up when HITRUST QA reviews it. Your organization owns the decision, and the assessor approves any override before submission.
Confirm the assessment type and scope letter
Start by checking which assessment you are running (e1, i1 or r2) and which scope letter and systems the assessment covers. The N/A rules differ by assessment, especially for third parties, so the rules you apply must match the assessment type. Your compliance lead records the assessment type and the approved scope in the requirement's working notes. This step is complete when every reviewer agrees on the assessment type and the scope boundary you will test against.
Inventory every system, facility and third party
For the requirement in question, list each system, facility and third party that falls within the assessment scope. Include components that sit under a shared service or inherited control, because the rationale must address them too. Mark each entry as in scope for the requirement or as a third party handled under a documented carve-out where the assessment type allows one. The output is a scope list for that requirement, reviewed by the control owner and the person who maintains the scope definition.
Write a rationale that addresses each scope item
Write the rationale so that every item on the scope list is covered by a specific reason the requirement does not apply to it. Avoid reasons that only say the activity does not occur, and avoid reasons that only say a third party performs the work, since neither is valid on its own. Where a third party is carved out under an e1 or i1, state the documented responsibilities and the fact that it is removed from scoring. The output is the rationale text, attached to the requirement and cross-referenced to the scope list.
Check for mixed applicability
Compare the N/A decision with the rest of the assessment. If the same service is scored elsewhere in the assessment, the requirement marked N/A creates mixed applicability, which HITRUST flags. Review monitoring requirements separately, since some typically cannot be marked N/A. The output is a short review note recording each service checked, whether it is scored elsewhere, and the change made if a conflict was found.
Run MyCSF automated quality checks
Run the automated quality checks in MyCSF before submitting the assessment. The checks flag potential quality issues, including rationale problems that a reviewer would likely reject. Save the results as a quality-check log that lists each flag, the requirement it applies to and its current status. The step is complete when every flag appears in the log with a status of fixed or pending override.
Fix each issue or document an override
For each flagged issue, either correct the rationale or scope list so the flag clears, or record a written explanation for why the flag does not apply. Do not override a flag to avoid rework. Each explanation should name the specific fact that makes the flag inaccurate. The output is an updated quality-check log where every item is either resolved or carries a written override explanation.
Obtain assessor approval for overrides
Send each override explanation to your assessor for approval. Overrides only take effect once the assessor approves them. Keep the approval record with the override explanation, the date and the assessor's name. The output is an approved override record for each override. Overrides are then reviewed in HITRUST QA, so the record should stand on its own without verbal context.
Confirm HITRUST QA review readiness
Before final submission, reread each N/A rationale against its scope list and the approved override record. Confirm that every rationale is complete, that no scope item is missing, and that every override has an approval. Store the scope list, rationale text, quality-check log and override records together so they are available when HITRUST QA asks for them. The step is complete when the package can be reviewed without further explanation from your team.
Where N/A decisions cause rework in the readiness phase
N/A decisions are easy to make early and expensive to unwind late. The four pitfalls below share a root cause: an N/A marking is only as good as the scope, third-party and occurrence facts behind it, and those facts change during readiness.
Setting N/A early and never revisiting it
Teams often mark requirements N/A during the first scoping pass and then move on. When a system joins scope, a facility is added or a third party changes role, the earlier marking may no longer hold, and no one rechecks it. The delay shows up in QA, when the assessor flags requirements whose rationale describes a scope that no longer exists. Check: after every scope change, re-run every N/A rationale against the current system, facility and third-party list before fieldwork planning continues.
Rationales that restate the requirement
A rationale that repeats the requirement text, such as saying the control is not needed because the organization does not perform the activity, gives the assessor nothing to test. QA expects the rationale to name the specific systems, facilities and third parties in scope and explain why each does not need the requirement. This pushes rework into the readiness phase, when the team must rewrite entries across many requirements. Check: every rationale should name at least one in-scope component and state the reason it is excluded.
Assuming an r2 allows carve-outs
Teams that have carved out a service provider for an e1 or i1 sometimes carry the same approach into an r2. The r2 does not allow service provider requirements to be carved out, so the N/A marking and the removed scoring will not stand. This can force a reset of scope and requirement statements late in readiness. Check: confirm the assessment type before applying any carve-out, and confirm with the assessor whether each third party must instead be assessed or covered through inheritance.
Unexplained overrides that fail review
MyCSF runs automated quality checks before submission, and each potential issue must be fixed or overridden with an explanation. Overrides need approval from the assessor and are reviewed again in HITRUST QA. An override with a thin or missing explanation, especially one that touches an N/A marking, is likely to be returned and can delay submission. Check: before submission, list every override, record the explanation and the approving assessor, and confirm each one reads clearly to someone outside the team.
Common questions about N/A requirements in HITRUST
Can a HITRUST requirement be marked N/A because our cloud provider performs it?
Usually no. A third party performing a requirement is not a valid reason for N/A, except under a documented e1 or i1 carve-out. Under an r2, service provider requirements cannot be carved out at all, so the requirement stays in scope and is answered through inheritance, the provider's evidence or your own controls. Your rationale must cover every system, facility and third party in scope. Confirm with your External Assessor how the provider's responsibilities are documented in your assessment before you mark anything N/A.
Does an e1 carve-out remove the need for an N/A rationale?
No. A carve-out does not replace the rationale. In an e1 or i1, a third party can be carved out only if its responsibilities are documented, it is removed from scoring entirely, and the requirements it fully owns are marked N/A with a rationale. The carve-out sets the scope boundary, and the N/A rationale explains each requirement. Missing either part is a common reason for QA to reject the decision, so check both before submission.
How does an N/A decision differ from r2 tailoring?
Tailoring decides which requirement statements are in your r2 at all, based on your answers to the risk-based scoping questionnaire in MyCSF. An N/A is a decision about a statement that is already in scope and that you believe does not apply to a particular system, facility or third party. Any factor answered No in the questionnaire needs its own written rationale. Changing a factor later can count as a significant change, so tailoring and N/A should be decided together and kept consistent.
Does a readiness assessment check our N/A decisions?
A readiness assessment can review your N/A rationales and point out weak ones, but it is not a HITRUST validated assessment and carries no HITRUST QA. The formal check happens during the validated assessment, when MyCSF runs automated quality checks before submission and the External Assessor reviews each flagged item. Ask the readiness provider to say explicitly whether it reviews N/A rationales, and what it will not sign off on.
Who approves an override of an N/A quality issue?
Overrides are not self-approved. Each potential quality issue in MyCSF must be fixed or overridden with an explanation. The assessor approves the override, and HITRUST reviews it in its quality assurance process. Your team should write the explanation as if the reviewer has no prior context, citing the specific system, facility or third party and the reason the activity does not occur or is owned elsewhere. Vague overrides are the ones most likely to come back.
What does the internal team need to provide for N/A decisions?
The internal team must own the facts behind each decision. Expect to provide:
- An inventory of systems, facilities and third parties in scope, so each rationale covers all of them
- Current architecture and data flow documentation showing where the requirement's activity does or does not occur
- Contracts and responsibility matrices for any carved-out or external party
- Evidence that an activity has not occurred, such as logs or change records for the review period
The assessor will test these facts, so each rationale should point to documents that already exist.
Can our internal team write N/A rationales without outside help?
Yes, many teams do, provided they understand the rules: a rationale must cover every system, facility and third party in scope, non-occurrence is never a valid reason, and mixed applicability is flagged when a requirement is N/A for a service scored elsewhere. The harder part is knowing which requirements can never be N/A, such as certain monitoring requirements, and how the assessor will read the evidence. Confirm with your External Assessor which decisions it wants reviewed early. An implementation partner can prepare documentation and evidence, but only the assessor and HITRUST decide what is accepted.
What makes N/A work take more effort?
Effort rises with the number of systems, facilities and third parties in scope, because each N/A must be justified for each of them. It also rises with the number of carve-outs, mixed applicability across services, and requirements that touch shared infrastructure or inherited controls. Weak or undocumented ownership boundaries and frequent architecture changes add rework. To scope the work, ask for the list of N/A decisions you expect, the evidence each one needs, and which items your assessor has flagged as likely to be challenged.
How DeployOpen prepares N/A decisions and evidence before assessment
DeployOpen helps teams prepare their N/A rationales and the evidence behind them before an assessor reviews the scope. The organization keeps ownership of every applicability decision, and DeployOpen prepares the systems, documentation and evidence that let those decisions hold up in HITRUST QA.
How we scope
- Each engagement starts with a written scope that lists which requirement statements are under review for N/A.
- We map every system, facility and third party in the assessment scope against each proposed N/A rationale.
- We flag any requirement marked N/A for a service that is scored elsewhere, so mixed applicability is caught early.
How we build
- We document the rationale for each N/A decision in a form the organization can defend line by line.
- We check carve-out documentation for e1 and i1 third parties, confirming responsibilities and scoring removal are recorded.
- We prepare evidence showing a control is not applicable, such as configuration records, and confirm it matches the stated rationale.
How we hand over
- We deliver a register of N/A decisions with rationale, scope references and supporting artifacts for the organization and its assessor.
- We record open questions the assessor must confirm, so nothing is left for QA to discover during submission.
- We provide a summary of which requirements can never be marked N/A and why those remain in scope.
How we support
- Ongoing support and upgrades are available as a retainer, which can cover updates to N/A rationales after scope changes.
- Ask us to review rationales again when systems, facilities or third parties change during the assessment window.
- Confirm with your independent assessor which rationale formats and override approvals they expect before work begins.
