HITRUST CSF Compliance Guide: e1, i1, r2, PRISMA, MyCSF, and the Operating Record
HITRUST CSF is one of the most demanding enterprise compliance frameworks in active use, and it is also one of the most useful when treated as an operating model rather than a project. This guide is written for the internal security teams, GRC and compliance teams, AppSec leads, and CISOs who own a HITRUST programme: choosing the right assessment type, getting the factor profile correct, structuring the evidence pack, surviving the External Assessor engagement, passing HITRUST QA without clarification storms, and producing a certification that holds up under enterprise customer scrutiny.
The framework consolidates HIPAA, ISO/IEC 27001, NIST SP 800-53, NIST SP 800-171, PCI DSS, GDPR, FFIEC, and many sector regulations into one tailored control set, scored across the PRISMA maturity model and validated by HITRUST QA. Run well, a single CSF programme answers most of the questions an enterprise security buyer asks in a vendor risk assessment. Run badly, it turns into a spreadsheet-and-screenshot scramble that drains security engineering capacity for two years and produces a brittle certificate.
What HITRUST CSF Actually Is, and Who Should Care
HITRUST CSF is a tailored, risk-based control framework operated by HITRUST. Unlike ISO/IEC 27001 or SOC 2, the CSF is not flat. The requirement set is selected by a factor profile so two organisations certifying against the same framework can land at very different requirement counts. The CSF also carries an explicit cross-framework mapping into HIPAA, ISO/IEC 27001, NIST SP 800-53, NIST SP 800-171, PCI DSS, GDPR, FFIEC, and many sector and state regulations. A single requirement can produce citations into multiple regimes when the evidence is structured correctly.
HITRUST is most often required of healthcare technology vendors, business associates, payers, providers, and any cloud or SaaS supplier that processes regulated data. Increasingly, fintech, government technology, B2B SaaS vendors, and AI platforms also adopt HITRUST because a single validated assessment answers questions across many customer security questionnaires that otherwise force per-customer custom responses.
Compare HITRUST against SOC 2 for startups and the ISO 27001 audit checklist and the distinction is the depth of evidence the framework requires. SOC 2 is an attestation by a CPA firm. ISO 27001 is a certification against a flat control set with documented exclusions. HITRUST is a validated assessment scored across five maturity levels per requirement and independently QA-reviewed before certification. The bar is higher; the programme cost is correspondingly higher; the certificate is correspondingly more load-bearing in enterprise procurement.
Choosing the Assessment Type: e1, i1, or r2
HITRUST publishes three validated assessment types. Selecting the wrong type is expensive on both sides; align the choice to the buyer requirement, the regulatory exposure, and the runway available before certification is needed.
Around 44 controls focused on foundational cybersecurity hygiene. The certificate runs for one year. The e1 is the right entry point for smaller vendors and for programmes whose buyer requirement is a baseline assurance rather than a deep regulatory commitment. The e1 is not a stepping-stone to r2 in the strict sense; most r2 programmes start the r2 process directly with a readiness phase rather than walking up through e1 then i1.
Around 182 controls drawn from a leading-practice baseline that emphasises implementation. The certificate runs for one year. The i1 fits programmes whose buyer requirement is meaningful but not r2-grade, and whose maturity supports Implemented-level evidence across the full set. The i1 is also a common interim position for programmes building toward r2 across multiple cycles.
The flagship validated assessment. The requirement set is tailored by the factor profile and typically lands between 200 and 2,000+ requirements. The certificate runs for two years with an interim review at month 12. PRISMA scoring expects evidence across Policy, Process, Implemented, Measured, and Managed levels. The r2 is the assessment enterprise healthcare and regulated-industry buyers commonly expect, and it is the one most likely to require cross-framework mapping into HIPAA, ISO 27001, SOC 2, NIST 800-53, PCI DSS, and GDPR.
Anchor the choice in three signals. First, the buyer requirement: many large healthcare and payer customers expect r2; a single-customer e1 expectation is rare and worth confirming. Second, the regulatory exposure: programmes carrying HIPAA, HHS OCR scrutiny, or state breach laws benefit from r2 cross-framework mapping. Third, the runway: r2 first-time certification commonly runs 9 to 18 months from factor-profile selection to certification issued. If the buyer deadline is non-negotiable, i1 or a bridge assessment may be the correct interim position while the r2 programme builds.
Factor-Based Scoping and Why Getting It Right Matters
The CSF is tailored, not flat. Each engagement begins with a factor profile that drives the requirement set selection in MyCSF. The profile captures organisational size, regulatory environment, system characteristics, and risk factors. The mechanism is useful: it keeps the assessment proportionate to the actual risk exposure. The mechanism is also the single largest source of expensive mistakes when programmes get the profile wrong.
Common factor profile fields include the number of records processed, the regulatory regimes in scope (HIPAA, GDPR, GLBA, PCI DSS, FedRAMP, state breach laws, the EU NIS2 directive, the EU Cyber Resilience Act), whether the system is third-party hosted or self-hosted, whether the application is internet-accessible, whether mobile clients access the system, the number of users, and the transaction volume. The mechanism multiplies the requirement count when the factor profile indicates higher risk and shrinks it when the profile indicates lower risk.
Two consequences follow. First, the factor profile is a strategic choice that the programme owner makes in collaboration with the External Assessor and the security leader; it is not a checkbox the operator runs through quickly. Second, the profile decision is auditable. If the External Assessor and HITRUST QA disagree with the self-reported profile, the requirement set re-scopes and the evidence pack the team has built no longer covers the right surface. Get the profile right before the evidence pack is built.
The 14 CSF Control Categories
HITRUST organises CSF requirements into 14 control categories. Most r2 evidence is produced once at the underlying control level and projected into the categories the requirement set actually exercises. The categories below describe the surface every programme has to staff and evidence.
Governance, the documented programme charter, the named information security officer, the documented review cadence, and the executive-level oversight evidence. This is where the leadership artefact pack lives.
Identity, authentication, authorisation, MFA, joiner-mover-leaver controls, privileged access review, and segregation of duties. This is one of the densest categories by requirement count in r2.
Background screening, security awareness training, role-based training, disciplinary processes, and the joiner-mover-leaver evidence on the HR side. Pair with the security awareness training programme guide for evidence design.
The documented risk assessment methodology, the risk register, the risk treatment plan, and the residual risk approval evidence. This is the category that determines whether the rest of the programme reads as risk-based or as a compliance checklist.
The information security policy stack, the document review cadence, the version control, and the approval evidence. Policies that exist only as static documents and are never revisited score Process at best.
The committee structures, the named owners per control area, the role descriptions, and the segregation-of-duties evidence at the organisation level.
The compliance obligation register, the regulatory environment mapping, and the evidence that the programme is configured against the actual regulatory exposure. Pair with the security compliance automation guide for the operating-side design.
The asset inventory, the asset classification, the ownership record, and the lifecycle evidence (acquisition through decommissioning). This is where the asset surface the rest of the programme reads against lives.
Facility access, environmental controls, secure-area designation, and equipment disposal. For cloud-native programmes this category is often satisfied through inherited evidence from the cloud provider attestations.
Change management, capacity management, backup, anti-malware, network controls, monitoring and logging, vulnerability management, and incident response operations. This is one of the densest categories.
Secure SDLC, cryptography, secure-coding evidence, change control on developed systems, and the AppSec evidence pack. Pair with the secure code review checklist and the NIST SSDF implementation guide.
The incident response plan, the documented incident classification, the response timeline evidence, and the post-incident review. Pair with the incident response plan guide and the incident postmortem guide.
The business continuity plan, the disaster recovery plan, the recovery time and point objectives, and the exercise evidence. The exercise evidence is what separates Implemented from Measured and Managed in this category.
The privacy notice, the consent records, the data subject request evidence, the cross-border transfer mechanism, and the breach notification record. This is the category that maps most heavily into GDPR and US state privacy law obligations.
PRISMA Scoring: Policy, Process, Implemented, Measured, Managed
Each CSF requirement is scored across five maturity levels. The scoring model is what separates HITRUST from a flat checklist framework. Programmes that aim only at documentation plateau at Process; programmes that operationalise the control reach Implemented; programmes that also measure and review the control reach Measured and Managed.
The documented expectation. A versioned policy with a named owner, an effective date, a review cadence, and an approval signature. Missing or unowned policies drop the score immediately.
The documented procedure that operationalises the policy. A standard operating procedure, a runbook, or a documented workflow with named role assignments. Process can score independent of evidence of execution.
Production evidence the control is operating. Configuration snapshots, scan output, access records, deployment logs, screenshots, and engagement records captured during the observation period. This is the level most first-time programmes target across the requirement set.
Defined metrics for the control with a documented collection cadence and a target threshold. Vulnerability remediation SLA adherence, access review completion rates, training completion rates, and incident response timeline metrics are examples. Pair with the security programme KPI framework for the metric design discipline.
Closed-loop review where the measurement drives change. The metric is reviewed on a documented cadence, the deviation triggers a documented response, and the response is captured as a change to the control. Managed is the level programmes target on the controls that genuinely drive risk reduction; reaching it across the entire requirement set is unrealistic for most programmes.
The scoring weights at each level contribute to the overall requirement score. A policy-only control scores well below an Implemented control with Measured evidence, even if both are technically present. Programmes that want a high r2 score have to reach Measured and Managed on the controls that materially drive the certification, not only on the easy ones.
Designing the Evidence Pack the External Assessor Reads
The evidence pack is what the External Assessor scores against. The pack quality is the single biggest determinant of HITRUST QA clarification volume. A pack that pulls from a structured operating record reads consistent across requirements; a pack assembled from screenshots and emails reads inconsistent and produces clarification storms.
The principle is simple: respond from the live operating record rather than authoring a parallel summary for the assessment. Vulnerability scan history, finding remediation records, the engagement activity log, the CVSS calibration record, the retest evidence, the credential rotation log, the team membership history, the policy version stack, and the configuration snapshots are all pulled from the underlying workflow rather than re-authored. The audit-grade evidence pack discipline is the same as the one explained in the operational audit fieldwork evidence request fulfillment workflow and the upstream audit evidence retention workflow.
Pack components every HITRUST evidence response should reference rather than recreate:
- Vulnerability scan output across the observation period with the scanner module, the asset, the finding, and the CVSS vector.
- Penetration test reports with the engagement record, the methodology, the testing window, the findings raised, the remediation evidence, and the retest result.
- Findings remediation history per finding with the open date, the close date, the named owner, the linked engagement, and the activity log entries.
- The activity log export as the canonical chronology of every change with timestamp and user attribution.
- Document versions for policies, procedures, runbooks, and standards with the effective date and the approval signature.
- Team membership history with the role, the granted-on date, the revoked-on date, and the named approver.
- Configuration snapshots from scanner output and from the configuration management system with the capture timestamp.
- Incident records with the timeline, the severity rating, the named responders, and the post-incident review note.
- Training completion records with the named participant, the completion date, and the role coverage map.
- Access review records with the named reviewer, the review cycle, and the documented attestation.
Penetration Testing and Vulnerability Management Evidence
HITRUST CSF expects regular vulnerability scanning across in-scope assets and, for environments above a factor-driven threshold, penetration testing as part of secure development and vulnerability management requirements. The expectation is documented scope, recognised methodology, CVSS-scored findings, remediation tracking with named owners, and re-test evidence before the certification window.
Recognised methodologies the External Assessor commonly expects include PTES, NIST SP 800-115, OWASP WSTG for web applications, OWASP ASVS for application security verification, and OWASP MASVS for mobile. The methodology reference is not optional; attestation language without a documented methodology reads as a control gap. Pair this with the penetration testing methodology guide for the operating model and the web application penetration testing checklist for the per-engagement coverage.
Vulnerability scanning evidence the External Assessor reads against:
- The documented scan schedule across external attack surface, authenticated internal, and code scanning.
- The scan-target inventory and the asset binding evidence so the scan coverage maps cleanly to the asset register.
- The scan output per cycle with the finding list, the CVSS vector, and the asset binding.
- The remediation status per finding with the open date, the close date, the named owner, and the retest evidence.
- The exception register for findings carrying a documented risk acceptance with the named approver and the review date.
Penetration testing evidence the External Assessor reads against:
- The engagement record per test with the scope, the testing window, the methodology, the named tester, and the report version.
- The findings raised by each test with the CVSS scoring, the severity, and the evidence pack the tester captured.
- The remediation evidence per finding with the resolution timeline and the linked ticket or change record.
- The retest evidence per finding before the certification window closes.
- The attestation letter released to the assessor as the redacted artefact where the full report is gated by NDA.
Cross-Framework Mapping: HIPAA, ISO 27001, SOC 2, NIST 800-53, PCI DSS, GDPR
HITRUST CSF was originally built to operationalise HIPAA and it inherits or maps to ISO/IEC 27001, NIST SP 800-53, NIST SP 800-171, PCI DSS, GDPR, FISMA, FFIEC, and a range of state and sector regulations. A single CSF requirement can carry citations into multiple regimes when the underlying evidence is structured for reuse.
The crosswalk discipline is what turns HITRUST from a separate audit into a multi-framework programme. The principle is: map the underlying control once, then project the evidence into each framework. The operational model for this is described in the control mapping cross-framework crosswalks workflow and the underlying economics is covered in the multi-framework control crosswalk economics research.
Common projection patterns:
- CSF Access Control requirements project into HIPAA 164.312(a) (technical safeguards), ISO 27001 Annex A.5.15-A.5.18 (access control), NIST SP 800-53 AC-2 through AC-6, SOC 2 CC6.1-CC6.3, and PCI DSS Requirement 7 (restrict access by business need).
- CSF Vulnerability Management requirements project into ISO 27001 Annex A.8.8 (management of technical vulnerabilities), NIST SP 800-53 RA-5 and SI-2, SOC 2 CC7.1, and PCI DSS Requirement 6.3 (vulnerability identification) and 11.3 (penetration testing).
- CSF Incident Management requirements project into HIPAA 164.308(a)(6), ISO 27001 Annex A.5.24-A.5.27, NIST SP 800-53 IR-4 through IR-8, SOC 2 CC7.3-CC7.5, and PCI DSS Requirement 12.10.
- CSF Privacy Practices project into GDPR Articles 5, 25, 28, 32, and 33, and into US state privacy law (CCPA, VCDPA, CPA, CTDPA, UCPA) where the operator processes residents of those states.
- CSF Risk Management requirements project into ISO/IEC 27005, NIST SP 800-30, and ISO 31000 risk methodology citations.
See the underlying framework references at /frameworks/hitrust, /frameworks/iso-27001, /frameworks/soc-2, /frameworks/nist-800-53, /frameworks/pci-dss, and /frameworks/hipaa.
The Validated Assessment Engagement: Scoping Through Certification
A validated assessment is a multi-stage engagement that runs from scoping through certification with several handoff points where the programme stalls if the operating record is not in shape.
The factor profile is finalised, the assessment type selected, the in-scope systems defined, and the responsibility model documented. The External Assessor is often involved at this stage. The output is the agreed scope and the requirement set count.
The programme selects an authorised External Assessor based on industry experience, cost, capacity, and the cycle deadline. The contract is signed and the engagement opens. This stage is often the gate that determines the rest of the timeline.
The team builds out the evidence pack against the tailored requirement set. Gaps surface here. The programme either remediates the gap before fieldwork or documents a risk-acceptance with the named approver for the External Assessor to read. Readiness is where most r2 first-time programmes spend the largest share of their calendar.
The External Assessor performs the assessment, reviews the evidence per requirement, conducts walkthroughs, scores PRISMA, and submits the result to HITRUST. The cleaner the evidence pack, the shorter the fieldwork. The structure described in the audit fieldwork evidence request fulfillment workflow applies directly to HITRUST fieldwork.
HITRUST QA independently validates the External Assessor submission. Clarifications and rescore requests are common. The QA cycle length is largely determined by evidence pack consistency and the External Assessor scoring rationale. Programmes with strong operating records typically pass QA with fewer clarification rounds.
HITRUST issues the certification record. The certificate carries the assessment type (e1, i1, r2), the validity period, and the in-scope systems. The certificate is the artefact released to customers in security questionnaires and vendor risk assessments.
For r2 certifications, the interim review checks that the programme continues to operate at the certified level. The interim is materially smaller than a full assessment but it is not a paperwork exercise; programmes that drift between full assessments fail the interim and lose the certification.
Common HITRUST Failure Modes and How To Avoid Them
Most HITRUST programmes that struggle fail in predictable places. Treating the CSF as a project rather than an operating model is the underlying pattern; the symptoms below are how the pattern surfaces.
The factor profile is gamed to shrink the requirement count. The External Assessor or HITRUST QA disagrees, the scope re-opens, and the evidence pack the team has built no longer covers the right surface. Get the profile right early and validate with the External Assessor before the pack is built.
The team builds a parallel evidence binder that describes what should be happening rather than pulling from the live record. The External Assessor compares the binder to the operating record and finds the inconsistencies. The fix is responding from the live engagement, the live findings, the live activity log, and the live policy stack.
The control narrative says regular pentests and scans are performed. The supporting evidence is a single PDF without the engagement record, the methodology, the CVSS-scored findings, the remediation history, or the retest evidence. PRISMA scoring lands at Process, not Implemented. The fix is wiring the pentest and scan records into the evidence pack so each requirement has the underlying operational record cited.
The same underlying control (access review, vulnerability remediation, incident response) produces a different artefact for HITRUST, SOC 2, ISO 27001, and the customer security questionnaire. Each artefact is independently authored. Drift accumulates and the audit response time grows linearly with the number of audits. The fix is mapping the underlying control once and projecting the evidence into each framework rather than recreating it.
A request lands in a shared inbox or a Slack channel and waits for whoever has bandwidth. Three days pass and the named owner is still ambiguous. The fix is routing each request item to a named owner with RBAC at ingest and surfacing the pending and overdue queues on notifications so the named owner reads against the queue rather than against the room.
The r2 interim at month 12 is treated as a re-attestation rather than as a control check. The programme has drifted, the underlying record does not support the certified score, and the certification lapses. The fix is operating the CSF as the day-to-day model so the interim reads consistent with the certification, not as a separate effort.
How SecPortal Supports a HITRUST CSF Programme
SecPortal is the operating-side record the HITRUST programme runs on. It is not the MyCSF submission platform; HITRUST operates MyCSF as the certification record. SecPortal holds the underlying evidence the programme pulls from when the External Assessor scores against the requirement set, when HITRUST QA reviews the submission, and when the certification record is built. The evidence stays consistent with what the team operates against day to day.
The capabilities that map directly to HITRUST evidence expectations:
- Engagement management holds the HITRUST assessment cycle, the readiness phase, the External Assessor engagement, the interim review (for r2), and the linked evidence sources.
- Findings management exports vulnerability and penetration testing evidence per requirement with the CVSS vector, the open and close dates, the named owner, the remediation history, and the retest evidence.
- Document management holds policy versions, procedures, runbooks, configuration snapshots, walkthrough notes, and attestation letters as versioned artefacts with effective dates and named owners.
- Compliance tracking maps requirements to the underlying CSF categories and to HIPAA, ISO 27001, SOC 2, NIST SP 800-53, PCI DSS, and GDPR so cross-framework projection happens once rather than per audit.
- External scanning, authenticated scanning, and code scanning produce the recurring scan output and the asset-bound finding evidence the External Assessor reads against the vulnerability management category.
- Team management role-based access scopes who can release what so sensitive evidence (raw findings, configuration snapshots, customer data samples) routes through the named approver before reaching the External Assessor channel.
- MFA enforcement protects the workspace and the portal that the External Assessor accesses so the audit response surface meets the access-control evidence expectation in the CSF itself.
- The branded client portal on a tenant subdomain hosts the External Assessor reviewer access scoped to the named assessor, with watermarked exports and access expiry tied to the assessment window.
- The activity log captures every state transition on every engagement, finding, scan, policy version, and team membership change with timestamp and user attribution. The CSV export is the provenance trail HITRUST QA reviews against.
- AI report generation composes summary evidence from the live record so the artefact pack the team releases reads consistent with the underlying operating record.
The operational workflows that turn this into a programme rather than a project run against the same record:
- Compliance audits for the broader audit operating model the HITRUST cycle sits inside.
- Audit evidence retention and disposal for the upstream discipline that decides what evidence is kept and for how long.
- Audit fieldwork evidence request fulfillment for the in-cycle response discipline that turns External Assessor requests into structured engagement items.
- Control mapping cross-framework crosswalks for the projection discipline that turns one canonical control into multi-framework citations.
- Control gap remediation for the post-readiness gap closure workflow.
- Vulnerability acceptance and exception management for the documented risk-acceptance evidence that supports findings carried into certification with an approved exception.
- Customer security evidence room for the downstream customer-facing release pipeline that reuses the same HITRUST certificate, the SOC 2 report, the ISO 27001 certificate, and the pentest attestation.
Who Runs the Programme Inside the Operator
HITRUST is not a single-owner programme. The roles below collaborate around the evidence record. The CSF expects the segregation of duties to be visible in the organisation of information security category, and the buyer-side review of the certificate often inspects the named roles.
- GRC and compliance teams own the assessment engagement, the External Assessor relationship, the MyCSF submission, and the cross-framework projection.
- CISOs and security leaders own the programme charter, the executive oversight, the management response to deficiencies, and the certificate as a business asset.
- Internal security teams own the day-to-day operating record the evidence pack pulls from.
- AppSec teams own the secure-SDLC, code-scanning, and AppSec testing evidence that supports the information-systems-acquisition-development-and-maintenance category.
- Vulnerability management teams own the scan output, the remediation tracking, and the exception register that support the vulnerability management requirements.
- Security operations leaders own the queue execution discipline that keeps the response from slipping behind the fieldwork clock and the interim review cadence.
- Product security teams own the per-product evidence pack when the certification scope covers multiple products with shared infrastructure.
Practical Next Steps for the Programme Owner
HITRUST CSF rewards programmes that operationalise the framework as the day-to-day operating model. The steps below describe the working approach internal security and GRC teams use to build a programme rather than a project.
- Confirm the assessment type (e1, i1, r2) against the actual buyer requirement and the regulatory exposure. Do not start with r2 if the buyer needs an i1 within four months; do not start with e1 if the buyer needs r2 within twelve.
- Build the factor profile with the External Assessor before constructing the evidence pack. The profile is the load-bearing input; getting it wrong wastes calendar.
- Stand up the operating record before stand-up of the evidence pack. Engagement management, findings management, document management, scan and pentest evidence, and the activity log are the source of truth the pack pulls from.
- Set the PRISMA target per requirement based on the underlying control importance. Aim Measured and Managed on controls that genuinely reduce risk; aim Implemented across the rest. Trying to reach Managed on the entire set is unrealistic and slow.
- Map the underlying control once. Project the evidence into HIPAA, ISO 27001, SOC 2, NIST SP 800-53, PCI DSS, and GDPR using the compliance tracking surface. Do not maintain parallel artefact stacks per audit.
- Wire the vulnerability management and penetration testing record into the evidence pack so the CSF Communications and Operations Management and Information Systems Acquisition, Development and Maintenance categories pull from live records rather than from attestation language.
- Run the External Assessor engagement as a structured engagement on the workspace rather than as a shared spreadsheet. Each PBC item is a tracked request with a named owner, a deadline, and a documented response artefact.
- Treat the r2 interim review as a control check, not as a paperwork exercise. The programme that operates the CSF day to day passes the interim with little additional effort; the programme that does not, loses the certification.
Run HITRUST as a Programme, Not as a Spreadsheet
SecPortal holds the operating record the HITRUST programme runs against: engagement management, findings management, scan and pentest evidence, document management, compliance tracking, team management, MFA, branded portal access for the External Assessor, activity-log provenance, and AI-composed summaries from the live record. The evidence pack you release into MyCSF stays consistent with what the team operates against day to day, so the External Assessor and HITRUST QA read against the same record the security team reads against.
Related Reads
- ISO 27001 audit checklist for the ISMS operating model the HITRUST programme commonly inherits from.
- SOC 2 compliance guide for SaaS companies and startups for the Trust Services Criteria background the CSF projects into.
- PCI DSS assessment guide for the QSA-led assessment model the CSF inherits citations from.
- Security compliance automation guide for the broader operating-model context.
- Security programme KPIs and metrics framework for the Measured and Managed level metric design.
- Vulnerability management programme guide for the vulnerability management category operating model.
- Risk-based vulnerability management buyer guide for the platform selection that supports CSF vulnerability requirements.
Frequently Asked Questions
HITRUST CSF is a tailored, risk-based control framework that consolidates HIPAA, ISO/IEC 27001, NIST SP 800-53, NIST SP 800-171, PCI DSS, GDPR, FFIEC, and many sector regulations into one operating model. Required most often of healthcare technology vendors, business associates, payers, providers, and any cloud or SaaS supplier that processes regulated data. Increasingly adopted by fintech, government technology, and B2B vendors that want a single validated assessment to answer multiple customer security questionnaires.
e1 is the essentials assessment with around 44 controls and a one-year certificate. i1 is the implemented assessment with around 182 controls and a one-year certificate. r2 is the flagship risk-based assessment with a tailored requirement set (200 to 2,000+ requirements) and a two-year certificate with an interim review at month 12. Choose by buyer requirement, regulatory exposure, and runway.
Factor-based scoping is the mechanism that tailors the HITRUST requirement set to the assessed entity. The factor profile captures organisational size, regulatory environment, system characteristics, and risk factors. MyCSF uses the profile to select the requirement set, so two organisations certifying against the same framework can land at very different requirement counts. Get the profile right early; rescoping mid-assessment is expensive.
PRISMA is the five-level maturity model HITRUST uses across every CSF requirement. Policy scores documented expectations. Process scores documented procedures. Implemented scores production evidence. Measured scores defined metrics with a collection cadence. Managed scores closed-loop review where measurement drives change. The scoring weights at each level contribute to the overall requirement score.
MyCSF is the HITRUST-operated platform that holds the System Security Plan, the tailored requirement set, the External Assessor scoring, and the certification record. Operators run the underlying security operating record (engagement management, findings management, document management, scan and pentest evidence, activity log) separately and link evidence into MyCSF when submitting.
Regular vulnerability scanning across in-scope assets and, for environments above a factor-driven threshold, penetration testing with documented scope, recognised methodology (PTES, NIST SP 800-115, OWASP WSTG, OWASP ASVS), CVSS-scored findings, remediation tracking per finding with named owners, and re-test evidence before the certification window.
e1 first-time runs 3 to 6 months. i1 first-time runs 6 to 9 months. r2 first-time runs 9 to 18 months. Renewals are shorter because the operating record carries forward and (for r2) the interim review keeps the programme in shape between full assessments.
HITRUST CSF inherits or maps to HIPAA, ISO/IEC 27001, NIST SP 800-53, NIST SP 800-171, PCI DSS, GDPR, FISMA, FFIEC, and a wide range of state and sector regulations. A single requirement can carry citations into multiple regimes when the underlying evidence is structured for reuse.
The External Assessor is a HITRUST-authorised assessor organisation that performs the validated assessment and scores each requirement across PRISMA. HITRUST QA is the independent quality validation HITRUST runs on the assessor submission before certification issues. Clarifications are common; pack quality determines the clarification volume.
A bridge assessment is the HITRUST-authorised mechanism for extending an existing certification when the next cycle is delayed, when significant scope changes occur, or when a transition between assessment types is in progress. Bridge assessments are time-bounded with a defined evidence expectation and are commonly used between an i1 expiring and an r2 first-time landing.
SecPortal holds the operating record the HITRUST programme runs on: engagement management for the assessment cycle, findings management for vulnerability and pentest evidence, document management for policy and procedure versions, compliance tracking for cross-framework mapping, team management for RBAC, MFA for access control evidence, branded portal access for the External Assessor, the activity log as the chronology, and AI-composed summaries from the live record. SecPortal is not the MyCSF submission platform; it is the operating record the team pulls evidence from when submitting into MyCSF.