01 Information Protection Program: HITRUST requirements

What the 01 Information Protection Program domain asks an organization to prove

If an e1, i1 or r2 is scheduled, domain 01 Information Protection Program is where the assessor starts, and it tests whether management owns a formal, current and approved information security program. The domain does not ask whether you bought the right tools. It asks whether the people accountable for the environment in scope have defined the program, approved it, and kept it in force. Everything the other 18 domains check, from access control to incident management, sits on top of this foundation, so a weak score here tends to drag down evidence that is otherwise sound.

The domain is tied to management ownership because HITRUST treats the program as an organizational commitment, not a product. In the CSF structure, the governance category for the security management program has a single control objective and a single control specification, which is small on paper but carries a lot of weight in testing. Assessors look for a written program with a named owner, policies that leadership has approved, roles that people actually hold, and a record that the program is reviewed on a schedule and updated after material changes. An in-scope cloud provider cannot supply this for you. HITRUST's inheritance guidance lists this domain as not inheritable from a cloud provider, so the customer must produce it.

This is also where programs most often fail. A program can exist as a document that nobody has reviewed since it was first written, with a policy approved by someone who no longer holds the role, and no budget or staffing that matches what it promises. Before you start readiness work, confirm with your own leadership: who signed the current program, when it was last reviewed, whether the security function has funding and authority to enforce it, and whether the review cycle produced dated minutes or sign-offs. Those answers, not the wording of the policy, are what a validated assessment examines.

Which parts of the organization fall inside the domain 01 scope

Domain 01 covers the management system that every other domain relies on, so its scope is set by who owns the program, not by which servers are assessed. The cards below cover the decisions that change the work most, from the legal entity boundary to the AI requirements added by an AI security add-on.

Legal entity and business units

Decide which legal entity and business units sit inside the assessed scope before anyone writes a policy. A policy set that covers one subsidiary but leaves a shared service team outside the boundary creates a gap an assessor will find quickly. Check whether shared executives, group policies and parent-company security functions are in scope, and document who approves exceptions for each unit.

Systems and data the program governs

The program must govern the systems and data inside the assessed environment, including the ones your teams run and the ones you rely on. Build an inventory that links each in-scope system to a named owner, a data classification and the policies that apply to it. Gaps usually appear where a system exists in a cloud account but is missing from the register.

Policy owners and security roles

Name the teams that own each policy and the security roles that run the program, such as the CISO, security governance staff and policy approvers. Record who reviews policies, how often, and who signs off. Assessors test whether these roles exist in practice, so role descriptions must match what people actually do.

Governance decisions owned by the customer

Governance, policy approval and management accountability for domain 01 cannot be inherited from a cloud provider. HITRUST's inheritance example lists this domain as not inheritable, so the customer must own its own information protection program even when the provider's infrastructure is already certified. Confirm this boundary with your assessor before you plan shared responsibility matrices.

AI security requirements in this domain

HITRUST's AI Security Assessment places AI security requirement statements in this domain, so an e1, i1 or r2 with the AI security certification adds work here. Identify which AI systems are in scope, who owns their governance, and which policies cover model use and data handling. Confirm the exact requirement statements with HITRUST's help material and your assessor.

Scope changes over time

Scope changes when a new business unit, system or AI tool joins the environment. Each change can add policy owners, inventory entries and governance decisions that must be reflected before the next assessment. Build a documented process that reviews scope at each change, so that the program stays aligned with the environment it governs.

How a HITRUST assessor tests the information protection program

This table sets out how an assessor typically tests each part of the information protection program, the evidence they ask for, and where programs usually fail. Read it as a preparation checklist: each row is a point the assessor will inspect as it operated during fieldwork, not only as written.

Test area	What the assessor inspects	Evidence usually requested	Common findings
Program scope	Whether the written program covers all in-scope systems, data, locations and third parties named in the assessment scope	Approved scope statement, system inventory, boundary diagram mapped to the program	Scope statement omits systems or business units that the assessed environment actually uses
Governance and ownership	Whether a management body oversees the program and receives reporting on it	Charter or terms of reference, meeting minutes, reports to the governing body	Governance body exists on paper but minutes show no security decisions or reviews
Policy approval	Whether policies are approved by management with a recorded date and version	Signed or recorded approval, version history, distribution records	Policies approved by an unnamed or inappropriate approver, or no approval date
Policy review cycle	Whether policies are reviewed at a defined interval and after significant change	Review log, change history, evidence of reviews performed during the fieldwork window	Stale policies that still reference retired systems, old roles or superseded standards
Role and owner assignment	Whether named individuals hold defined security responsibilities and have accepted them	Role descriptions, RACI or responsibility matrix, appointment records	Owners are undefined, vacant or assigned to people who no longer hold the role
Management review	Whether management reviews program performance, risks and open issues at planned intervals	Review agenda, minutes, actions raised and closed, metrics presented	Reviews are scheduled but not held, or actions are recorded without follow-up
Policy to practice	Whether operated controls match what the policies say, sampled across the fieldwork window	Samples of operating records that the policy requires, such as access approvals or exception logs	Policies describe a control that staff do not follow, so the assessor records a gap against practice
Exceptions and deviations	Whether approved exceptions to policy are documented, time limited and reviewed	Exception register with approver, rationale, expiry and review evidence	Exceptions are granted informally or never expire

How to build the program so domain 01 can be scored

This sequence turns the information protection program from an informal set of practices into a documented, approved and reviewed program with owners and traceable links to requirement statements. Each step leaves an artifact the assessor can inspect, which is what domain 01 is scored on.

Confirm scope and the executive owner
Start by fixing the boundary of the program: which business units, systems, data types and locations fall under it, and which assessment (e1, i1 or r2) and any add-ons, such as the AI security certification, the program must support. Name one executive who owns the program and has authority to approve policy and fund its work. Output: a signed scope statement and a named owner recorded in the program charter, so the assessor can see who is accountable for domain 01.
Write or revise the program document
Draft the information security management program document that describes objectives, the security principles the organization follows, how the program is governed and how it relates to the organization's risk appetite. Where a program already exists, compare it against the current CSF version in MyCSF and close gaps in wording before adding new content. Output: a versioned program document with a change history, not a loose draft in a shared folder.
Build the policy set and standards
Develop the policies that sit under the program document, covering the topics the other 18 domains depend on, such as acceptable use, access, acceptable risk handling, exceptions and third-party expectations. Keep each policy short, state who it applies to and assign a single owner per policy. Output: a policy register listing every policy, its owner, its version and the date it was last approved. Confirm the exact policy set against the current requirement statements in your assessment scope rather than assuming it.
Assign roles and governance committees
Define who does what: the executive owner, the security function that runs the program day to day, control owners in each domain, and a governance body, such as a security steering committee, that reviews exceptions and program health. Write down the meeting cadence and decision rights. Output: a roles and responsibilities matrix and committee terms of reference, with named individuals and their deputies, that show management ownership of the program.
Approve and publish the program
Obtain formal approval of the program document and policy set from the executive owner or the governing body, and record the approval date and approver on each document. Publish them to the staff who must follow them and capture acknowledgments where your policy requires it. Output: approval records and a publication log that an assessor can sample, showing the program was in force during the assessed period rather than written after the fact.
Set the review cadence and change control
Define how often the program document and each policy are reviewed, what triggers an early review (such as a significant change to scope, a security incident or a new CSF version), and how changes are approved and communicated. Keep the review schedule in the policy register. Output: a documented review calendar and a record of completed reviews, since assessors test whether the program is maintained as well as written.
Map each policy to requirement statements
Link every policy and program element to the requirement statements it satisfies in domain 01 and in the other domains it supports. Use a traceability matrix, maintained in a GRC tool or a spreadsheet, that shows each requirement, the policy that answers it, the owner and the evidence location. Check that every requirement in scope has at least one mapped policy and evidence source. Output: a complete traceability matrix that becomes the index for the assessment and shows where each requirement is met.

Evidence that passes domain 01 and how to keep it current

Domain 01 is judged on whether management owns the information security program and can show it operating over time. The artifacts below are the documents and records an assessor will ask for first, and the upkeep between assessments decides whether they still hold up. Treat each one as a living record with an owner, a review date and an approval trail.

Approved program charter

The charter sets the purpose, scope and authority of the information security program, and it names who in leadership approved it. Check that it covers every in-scope business unit, cloud account and system, and that the scope matches your HITRUST assessment boundary. Confirm the charter carries an approval date, a version and a named owner, and that the last review happened on the schedule you wrote into it. An assessor will compare the charter against the scope you present, so any drift between them is a finding waiting to happen.

Policy set with version history

Policies are the written rules the program enforces, and assessors look for a current version of each policy that management has approved. Keep a version history for every policy showing what changed, when, and who signed off. Between audits, check each review date against your own review cycle and retire or update any policy that refers to systems you no longer run. Stale policies that describe retired tools are among the easiest gaps to spot.

Role and responsibility matrix

The matrix shows which named roles own each part of the information protection program, from policy approval to exception handling. It must match the org chart and the access records, so a departed owner does not leave a control without an accountable person. Review it at least when staff change roles, and confirm that each role holder accepted the responsibility in writing. Where a responsibility sits with a cloud provider or vendor, state that split explicitly rather than leaving it implied.

Management review minutes

Minutes from management reviews show that leadership looked at the program, its risks and its open issues, and made decisions. Record attendance, the inputs reviewed, decisions taken and the owners of follow-up actions. Assessors test whether actions raised in one meeting were closed in later ones, so keep an action log that links back to each set of minutes. Schedule these reviews in advance so the record shows a steady cadence rather than a single meeting before the assessment.

Communication and acknowledgment record

This record shows that the policy set reached the people it applies to and that they acknowledged it. Keep distribution dates, the audience for each policy, and signed or electronically recorded acknowledgments. When a policy changes, issue the new version and track who has accepted it, then chase the gaps. Retain the record for the period your assessment window needs, and confirm the retention rule with your assessor before you rely on it.

Approval trail and document control

The approval trail ties every policy version, charter revision and matrix update to the person who approved it and the date of approval. Use a document system that keeps prior versions and records edits, so you can compare any two versions during fieldwork. Set a standing check, such as a monthly review of upcoming review dates, to catch documents that have passed their due date. Without this trail, even a good policy can be rejected because the assessor cannot tell which version was in force on a given day.

Why the program document alone does not score

Assessors do not score domain 01 on the existence of an information security policy set. They score whether the program is operated: whether the policies are referenced when people make real decisions, whether exceptions are requested, approved, time-limited and tracked, and whether management visibly acts on the results of its own reviews. A policy signed two years ago and never cited again is a document, not evidence of a program. Before an assessment, the reader should walk through three recent decisions (an access exception, a risk acceptance, a vendor onboarding) and confirm that each points to a written rule, a named approver and a recorded outcome.

Domain 01 is also the foundation the other 18 domains lean on. Roles and responsibilities defined here are what the access reviews in 11 Access Control, the risk decisions in 17 Risk Management and the vendor reviews in 14 Third-party Assurance are supposed to trace back to. When the governance record is thin, assessors often find that the same gap appears in several places at once: a control owner who cannot say who approved the standard it follows, or a review that happened but has no documented follow-up. One weak governance record can therefore lower scores across several domains, which is why the program needs to be checked as a system rather than one document at a time.

For the reader, the practical question is who owns each element and who can show the trail. Confirm with the assessor's current handbook how evidence of operation is expected to be sampled, and make sure the policy owner, the management reviewer and the person who tracks exceptions are named in the program itself. An implementation partner can help set up the records and review cycle so that they produce evidence as a side effect of normal work, but the policies must be approved and enforced by the organization's own leadership.

What meeting domain 01 costs in money and effort

This table breaks down the cost components of owning the information protection program that domain 01 requires, who is paid for each one, and whether it is one-time or recurring. Read it to see where spend goes before requesting a written scope and quote, since no price is published here.

Cost component	Who is paid or who bears the effort	One-time or recurring	What drives it up or down
Management time to own and approve the program	Internal: CISO, executive sponsor and governance committee. No external invoice, but real hours	Recurring, at each annual review	Number of business units in scope and how many decisions sit above the security team. Clear delegation and a standing review calendar keep it down
Policy writing and drafting	Internal staff, or an outside consultant if paid by the hour or by fixed scope	One-time build, then recurring updates	Number of policies, whether templates from existing frameworks are reused, and how many systems and third parties the policies must describe
Legal and privacy review of policies	Internal legal or outside counsel, billed separately	One-time for the first set, then at material changes	Jurisdictions, contract obligations and whether privacy requirements are tailored into the assessment. Ask whether the quote includes this review
Readiness support from an outside party	Implementation partner or consultant, under a written scope	One-time per readiness cycle, plus optional retainers	Maturity of existing governance records, number of gaps found, and whether the partner builds the program or only reviews it. Ask for deliverables by name
Wiki or GRC tooling for policies and evidence	Self-hosted open-source tools (for example, a wiki with version history or an open-source GRC platform) run in your own infrastructure, so license spend can be avoided. Hosting, administration and backups remain internal or contracted costs	Recurring for hosting and administration, one-time for setup	Whether a commercial GRC subscription is already paid for, how much configuration is needed, and who maintains the platform. Confirm each tool's license terms before adopting it
Evidence upkeep	Internal control owners who collect and retain approvals, review records and policy versions	Recurring throughout the certification period	Number of review cycles, how well approvals are captured at the time of decision, and whether version history is kept automatically
Assessor fees for fieldwork	Authorized HITRUST External Assessor organization, billed under its own engagement terms	One-time per validated assessment, with later assessments on the certification cycle	Assessment type and scope, the fieldwork window (at most 90 days for e1, i1 and r2), and how ready the evidence is when fieldwork starts. Request the assessor's fee schedule in writing

Who owns domain 01 and what can be outsourced

Your organization owns domain 01 in full. HITRUST's own guidance on inheritance is explicit that the customer must own its information protection program, governance and policies, so this domain cannot be inherited from a cloud provider or delegated to a vendor. Your leadership is accountable for the program, and the people who sign policies and accept risk must be your own staff. A partner can draft text, but it cannot make the decisions that the assessor will test.

Policy approval: Executives or the designated governing body must formally approve the information security policies, with dates and named approvers recorded.
Role assignments: Security leadership, control owners and the people accountable for each policy area must be named by your organization, not by an outside firm.
Scope and risk decisions: Decisions about which systems, business units and third parties are in scope, and which risks are accepted, belong to management.
Resourcing and review: Your team sets the review cycle, funds the program and confirms that staff follow the documented process in daily operations.
Evidence of operation: Meeting minutes, approval records and management reviews must show the program running, not only existing on paper.

Before you engage any outside party, confirm internally who will sign off each decision and how those approvals will be recorded in your own systems.

Gaps that most often weaken the domain 01 score

Domain 01 is scored on whether management owns the information protection program in practice, not only on whether documents exist. The gaps below share one root cause: the program is written down but not run, approved or kept current. Each card names a check you can run before an assessor does.

Policies never approved by management

A policy set drafted by the security team and posted on a wiki is not the same as one that management has approved. Assessors look for evidence that a named executive or governing body reviewed and adopted each policy, with the approval date and version recorded. Check that every policy in scope carries an approver, an approval date and a link to the minutes or sign-off record. If approval happened in an email thread, export it and file it with the policy.

No named owner for the program

Domain 01 is the one most tied to management ownership, so a program with no accountable person reads as unowned. The owner should hold authority over the program, not just administer it, and the role should appear in the organization's governance documents and job descriptions. Confirm the owner can name the policies they are accountable for, the forums where they report, and the budget they control. Where ownership is shared, write down who decides what.

Review dates that have passed

Policies with a stated review cycle that were not reviewed on time are an easy finding for an assessor, because the document itself shows the gap. Build a register that lists each policy, its owner, its last approval and its next review date, and run a monthly check for anything overdue. When a review finds no change is needed, record that decision and the reviewer's name so the review still leaves evidence.

Policies describing tools not in use

A policy that promises a control delivered by a tool the organization does not run, or has retired, is a contradiction an assessor will test. Examples include a policy citing a log retention platform that was never deployed, or a key management process that the engineering team bypasses. Map each policy statement to the system or procedure that performs it, and correct the policy wherever the wording outruns the reality. Accurate, modest policies score better than ambitious ones that are not operated.

AI security requirements left out

When an organization pursues HITRUST's AI security certification, its AI security requirement statements sit in this domain, so the program must address them too. Teams often add AI tooling without updating the governance, policy and ownership records that domain 01 depends on. Confirm the program covers the AI systems in scope, names an owner for AI security decisions, and states the approval path for new AI tools. Review the current AI Security Assessment help page to see which requirements apply to your certification.

Questions buyers ask about the domain 01 program

Is domain 01 more work than the technical domains?

Usually it takes less hands-on engineering time but demands more management time. Domain 01 covers governance, policies, roles and the program that the other 18 domains depend on, so the work is mostly decisions, written documents and evidence that leadership reviews and approves. Technical domains such as access control or audit logging need configured systems and exported records, which take engineering effort to produce and sample. Domain 01 is hard for a different reason: an assessor will test whether the program is real, owned and followed, and weak governance tends to surface as gaps across every other domain. Ask any partner to separate the governance workload from the technical workload in the written scope.

Can a partner write our information security policies for us?

A partner can draft policies, but the organization must adopt them, and an assessor will look for evidence that leadership approved and communicated them. Policies have to describe how your organization actually operates, so drafts built from a generic template tend to fail when staff cannot follow them or when the described controls do not exist. A sound approach is for the partner to prepare drafts from your current practices, your risk assessment and your chosen scope, then for named owners to review, edit and approve each document. Ask the partner which decisions remain yours, who signs each policy, and how revisions and approval dates will be recorded.

How long does it take before the program is ready for assessment?

The duration depends on how far your current program is from the requirement statements in scope, and no fixed timeline applies to every organization. Several elements take calendar time regardless of effort: leadership must approve policies, roles must be assigned and staff must be briefed, and the program needs to operate long enough to produce records. HITRUST's assessment handbook sets the validated assessment fieldwork window at up to 90 days for e1, i1 and r2, but that window covers the assessor's testing, not your preparation. Ask a partner for a readiness review first, then a written schedule that shows which governance items must be in place before the fieldwork starts.

Can our own team run the domain 01 program without outside help?

Yes, many organizations run the program in-house, provided the team has the authority, time and knowledge to do it. The work includes maintaining the policy set, tracking roles and responsibilities, running risk reviews, keeping approval records and collecting evidence on a steady schedule. Teams that succeed usually appoint a named security lead with an executive sponsor and build a simple calendar of recurring governance tasks. Outside help is most useful for a readiness gap review, for an independent check before the assessment, or for training internal staff on what an assessor will test. Whichever route you choose, confirm who owns each deliverable in writing.

What does domain 01 need from senior management?

Domain 01 needs visible, documented commitment from senior management, because the assessor will look for it directly. Leadership must approve the information security policies, assign accountable roles, provide resources for the program and review its performance at a set cadence. Managers should also be able to show that they reviewed risks, accepted residual risk where needed and responded to findings. In practice, this means scheduling management reviews, keeping minutes or approval records and making sure the people named in policies know their responsibilities. If leadership does not own the program, the other 18 domains will struggle to produce consistent evidence.

Does a cloud provider's HITRUST result cover our domain 01 program?

No. HITRUST's inheritance example lists domain 01 as not inheritable from a cloud provider, so the customer must own its information protection program, governance and policies. A provider's certified environment can supply some controls to your assessment, but your leadership, policy set and roles remain your responsibility. Review the shared responsibility matrix from your provider carefully and confirm which domains are inheritable and which are not. Your assessor will expect the governance evidence to come from your organization, even when the infrastructure controls are inherited.

Does the AI security certification add requirements to domain 01?

Yes. HITRUST's AI Security Assessment help page places AI security requirement statements in this domain, so an e1, i1 or r2 that includes the AI security certification adds requirements here. Your governance documents may need to address how AI systems are approved, who is accountable for them and how their risks are reviewed. Confirm the current requirement list in MyCSF with your assessor before you scope the work, since the requirement set depends on the assessment type and CSF version you select.

Using a self-hosted wiki and GRC tool to hold the program

A HITRUST assessor will ask who wrote each policy, who approved it, and whether the version in force is the one staff actually follow. A self-hosted wiki such as XWiki can answer those questions because it keeps every change under version control, recording what changed, when and by whom, and letting you compare any two versions or roll back to an earlier one. For the 01 Information Protection Program, that history is the evidence trail for the information security policy, the roles and responsibilities document and the review cycle. Confirm with your own environment that the wiki's backup and retention settings preserve that history for the full assessment period, and that the platform's audit trail is not editable by the people whose work it records.

Separating authors from approvers is a governance decision before it is a tool setting. In BookStack, user abilities come from the roles assigned to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. A practical model for this domain is one role that can create and edit policy pages, a second role that can publish or approve them, and read access for everyone in scope. Test the model by attempting an edit as an author on a page marked approved, and record the result. BookStack is released under the MIT license, so its use carries few licensing constraints, but you should still confirm that its permission model meets your management's approval requirements. Publish the role matrix itself as a policy page so the assessor can see who holds which authority.

CISO Assistant is licensed under AGPL-3.0-only, and that matters before you deploy it. The AGPL requires that users who interact with a modified version over a network can obtain its source, so legal review is needed if you change the code, embed it in another product or offer it to third parties. Using it unmodified internally usually carries lighter obligations, but have counsel confirm your position. Functionally, the tool ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and supports audits and compliance assessments with automatic mapping between frameworks. For HITRUST, it can hold the program's control mapping and assessment records, but it does not replace HITRUST's own scoring in MyCSF. Confirm whether it includes a HITRUST framework library in the version you deploy before relying on it for that purpose.

01 Information Protection Program