Framework

HITRUST CSF
factor scoping, PRISMA scoring, validated assessment

Run HITRUST CSF programmes end-to-end. Build the factor profile, complete readiness against the tailored requirement set, score evidence across the PRISMA maturity model, manage the External Assessor engagement, and produce the MyCSF submission and post-certification evidence pack from one workflow.

No credit card required. Free plan available forever.

The HITRUST CSF in practice: from factor scoping to validated certification

The Health Information Trust Alliance Common Security Framework (HITRUST CSF) is a certifiable control framework that consolidates HIPAA, HITECH, ISO/IEC 27001, NIST SP 800-53, NIST SP 800-171, PCI DSS, GDPR, FISMA, and a broad set of state and sector regulations into a single requirement set. It is governed by the HITRUST Alliance, run through the MyCSF platform, and certified by accredited External Assessor firms with independent quality assurance from HITRUST. The framework is most heavily adopted in healthcare and life sciences, where business associate due diligence and BAA counterparty risk drive demand for third-party validated assurance, but uptake has broadened into financial services, insurance, and regulated technology suppliers.

Most CSF programmes do not fail because the controls are missing. They fail because the factor profile is loose, the evidence pack lives across drives and tickets, and the PRISMA scoring at the requirement level penalises documented-but-static controls. SecPortal is built for the operating layer underneath the SSP: scoping, scans, findings, control mapping, business associate records, incident timelines, and the assessor-ready output all sit on linked records, so the validated submission reflects how the programme actually runs.

Choosing between e1, i1, and r2 (and the readiness work that sits in front of all three)

HITRUST publishes three validated assessment types plus the readiness and bridge work that feeds them. The choice is driven by the buyer or counterparty requirement, the regulatory exposure, and the runway available before certification is needed. Selecting the wrong type is expensive on both sides: an e1 cannot be retro-fitted into an i1, and an r2 attempted without the readiness step typically produces extensive QA cycles before certification.

e1: 1-year Essentials Assessment

A foundational assessment covering 44 controls focused on critical cybersecurity hygiene. Designed for smaller organisations and lower-risk environments where the cost and runway of an i1 or r2 assessment is not justified, but the buyer or BAA counterparty still wants third-party validated evidence rather than a self-attestation. Issued by an Authorised External Assessor through the MyCSF platform with a one-year certificate.

i1: 1-year Implemented, 1-year Validated

A moderate-assurance assessment covering roughly 182 controls drawn from the leading practice baseline. Targeted at organisations that handle sensitive information at a level above e1 hygiene but below the full r2 risk-tailored scope. The i1 report supports vendor risk reviews, BAA due diligence, and pre-r2 maturity work. Renewable annually with a one-year certificate.

r2: Risk-based, 2-year Validated

The flagship HITRUST CSF assessment. Scope is tailored using factors (organisation size, geography, regulatory environment, system characteristics) to produce a control set that typically ranges from around 200 to 2,000+ requirement statements. Each in-scope requirement is scored on the PRISMA maturity model across Policy, Process, Implemented, Measured, and Managed. Two-year certification with an interim review at month 12.

Readiness and bridge assessments

Readiness work runs ahead of a validated assessment to surface gaps in the SSP, control implementation, and evidence pack before the External Assessor begins formal fieldwork. Bridge assessments cover the gap between r2 cycles for buyers who require continuous evidence. Both are run by the same External Assessor community through MyCSF and feed directly into the validated submission.

Factor-based scoping: where most r2 cycles win or lose before fieldwork starts

The CSF is tailored, not flat. Each engagement begins with a factor profile that drives the requirement set selection in MyCSF. Two organisations certifying against the same framework can land at very different requirement counts because their factor profiles differ. Getting the profile right is the leverage step: it sets the depth of the assessment, the assessor effort, and the evidence pack the SSP has to support.

  • Organisational factors: total workforce headcount, total annual revenue, total record count, and geographic footprint of the systems in scope
  • Regulatory factors: HIPAA, HITECH, FISMA, FedRAMP, GDPR, NIST SP 800-171, PCI DSS, GLBA, NYDFS Part 500, state privacy laws, and any sector-specific regimes the system serves
  • System factors: number of users, number of records processed, transaction volume, internet-facing exposure, and the presence of cloud, mobile, IoT, or third-party hosting
  • The factor profile drives the requirement set selection; an r2 assessment for a small clinic and an r2 assessment for a multi-state payer can differ by an order of magnitude in requirement count even though both certify against the same underlying CSF
  • Scope errors at the factor stage are the most common cause of late-cycle rework: under-scoping leads to assessor pushback during validation, over-scoping inflates the work without adding assurance value

The 14 CSF control categories: where the requirement statements live

The CSF organises requirements into 14 control categories. Every requirement statement belongs to a category, and most categories produce evidence drawn from a mixture of documentation, configuration, scan output, and operational records. The clusters below group the categories the way most validated submissions actually shape evidence.

0. Information Security Management Programme

The governance baseline. Covers the documented security programme, leadership accountability, programme charter, programme review, and the risk management framework that the rest of the CSF sits inside. Maps cleanly to ISO 27001 Clauses 4 to 10 and to NIST SP 800-53 PM and PL families.

1-3. Access Control, Human Resources Security, Risk Management

Identity, authorisation, joiner-mover-leaver process, background screening, role-based training, and the risk-treatment record. These are the categories where an r2 validated assessment most often produces high-volume requirement statements because the scoping factors push depth across logical and physical access, privileged accounts, and administrative procedures.

4-6. Security Policy, Organisation of Information Security, Compliance

The policy hierarchy, internal organisation, external party governance, regulatory inventory, and the audit and review programme. Evidence here is documentation-heavy: policies with version history, review cadence, and management approval; regulatory inventory mapped to systems; and audit results with remediation traceability.

7-9. Asset Management, Physical and Environmental Security, Communications and Operations

Asset inventory, classification, media handling, physical access, environmental controls, change management, capacity management, malware protection, backup, network security, and electronic commerce. This is the largest category cluster on most assessments and the place authenticated and external scan output produces the densest evidence.

10-11. Information Systems Acquisition Development and Maintenance, Information Security Incident Management

Secure development lifecycle, change management, vulnerability management, application security testing, incident handling, and post-incident learning. Penetration test reports, vulnerability scan output, secure code review records, and incident timelines all attach here.

12-13. Business Continuity Management, Privacy Practices

BCDR planning, exercise records, recovery objectives, the privacy programme, data subject rights handling, consent management, and the privacy incident trail. The privacy category is where HITRUST CSF maps to GDPR, CCPA, and equivalent regimes alongside the HIPAA Privacy Rule.

For organisations that already run an ISO 27001 ISMS or a SOC 2 attestation, the category mapping is the practical leverage point: most r2 evidence is already produced by the existing programme and only needs enrichment for the PRISMA Measured and Managed levels.

PRISMA scoring: why a documented control does not automatically score

Each CSF requirement is scored across five PRISMA maturity levels. The score determines whether the requirement contributes to certification, and it is also the place where otherwise-mature programmes lose ground. The scoring rewards evidence drawn from production, with measurement and review on top, rather than documentation alone.

Policy (POL)

Is there a documented, approved, current policy that addresses the requirement? The artefact is the policy itself, with version, owner, approval signature, and review cadence. Missing or stale policy is the most common reason a requirement does not score at this level.

Process (PRO)

Is there a documented procedure or process that operationalises the policy? The artefact is the procedure: who does what, when, with what inputs and outputs. Process documents that paraphrase the policy without operational detail score low here even when the policy itself is in place.

Implemented (IMP)

Is the control actually deployed in the environment, with evidence drawn from production rather than from a test or non-representative sample? The artefact is configuration evidence, scan output, screenshots dated to the assessment window, and access records. Implemented is the threshold below which a requirement does not contribute meaningful assurance.

Measured (MEA)

Is the control performance measured, with metrics defined and collected on a documented cadence? The artefact is the metric definition, the measurement record, and the trend over time. Many otherwise-mature programmes plateau here because metrics exist but are not used to drive review.

Managed (MAN)

Is the measurement used to manage the control, with documented review, decision, and corrective action? The artefact is the management review minutes, the decision record, and the closed-loop evidence that measurement drove a change. Managed is the level that distinguishes programme-grade controls from documented-but-static controls.

The continuous monitoring capability produces the cadence and trend evidence the Measured and Managed levels expect, and the compliance tracking capability keeps the requirement-to-evidence linkage current as new systems and business associates enter scope.

The validated assessment lifecycle: scoping to certification to bridge

A validated assessment is a multi-stage engagement, not a single event. The lifecycle below tracks the stages every i1 and r2 assessment passes through, with the artefacts each stage produces. e1 follows a compressed version of the same shape.

  • Scoping: confirm the factor profile, the entity in scope, the systems and data flows in scope, and the assessment type (e1, i1, or r2)
  • Object selection: nominate the External Assessor, register the engagement in MyCSF, and confirm the requirement set drawn from the factor profile
  • Readiness: run a structured readiness review against the SSP and the evidence pack, surface gaps, remediate, and re-evidence
  • Fieldwork: the External Assessor reviews per-requirement evidence, runs sample testing, conducts interviews, and validates control implementation
  • Quality assurance: HITRUST runs the QA review on the assessor submission, returns clarifications, and confirms scoring
  • Certification: HITRUST issues the certificate (one year for e1 and i1, two years for r2) and posts the result in the assurance directory
  • Continuous monitoring: r2 includes an interim review at month 12; e1 and i1 renew annually; bridge assessments cover the gap between r2 cycles where the buyer requires continuous evidence

Penetration testing for HITRUST: scoped, methodology-aligned, and re-tested

The CSF expects vulnerability scanning and, for environments above a threshold defined by the factor profile, penetration testing as part of the secure development and vulnerability management categories. The expectation is documented scope, recognised methodology (PTES, NIST SP 800-115, OWASP WSTG), CVSS-scored findings, remediation status per finding, and a re-test result before certification. Loose attestation language in place of evidence is read as a control gap by both the External Assessor and the QA review.

The penetration testing workflow and the penetration testing methodology guide cover the structure used in HITRUST-aligned engagements. The web application penetration testing checklist is the most common starting point for patient portals and member portals, and the API security testing checklist extends the same workflow to FHIR APIs, claim adjudication APIs, and integration tiers.

The MyCSF evidence pack the External Assessor and QA review actually want

Build the evidence pack as the work happens, retain raw scanner output and test reports alongside the summary, and tie every artefact back to a CSF requirement, an asset, and an owner. The MyCSF submission expects per-requirement linkage, and pack quality is the single biggest determinant of QA clarification volume.

  • System Security Plan (SSP) describing the assessment scope, factor profile, system boundary, data flows, and per-requirement implementation, retained in the MyCSF platform alongside the validated submission
  • Policy and procedure library aligned to the CSF control categories with version history, owner, last review date, and the management approval record
  • Asset inventory linked to the factor profile with classification, ownership, hosting location, and the controls that apply to each asset class
  • Risk register tying every identified risk to a treatment decision, an owner, a target date, an evidence reference, and the residual risk acceptance signature
  • Authenticated scan output retained per scan window with mapping to the technical safeguard categories and the requirement statements they evidence
  • External scan output for the internet-facing perimeter with mapping to attack surface, exposure, and remediation history
  • Penetration test reports with scope, methodology, findings (CVSS-scored), remediation status, and the re-test result, retained against the engagement record
  • Code scanning output (SAST and SCA) for in-scope applications with finding history, fix verification, and the change management linkage
  • Incident response records: plan, tabletop exercises, and any actual incident handling with the post-incident review
  • Continuous monitoring records: scan cadence, audit log review, configuration change reports, and the metric trend evidence used at the Measured and Managed PRISMA levels

Common PRISMA scoring pitfalls that catch otherwise-mature programmes

The recurring failure patterns at QA review are not subtle once the evidence pack is examined. They are the gaps a structured workflow closes by construction.

  • Policy and Process scored without an Implemented artefact: paper-only programmes score low at the requirement level even when the documentation looks polished, because the maturity model rewards evidence drawn from production
  • Implemented evidence sampled from non-representative systems: a control evidenced on one server out of fifty does not carry across the rest of the population without sampling justification or population-wide evidence
  • Measured without a definition: a metric reported once is not a measurement; the requirement expects a defined cadence, a defined collection method, and a trend that can be reviewed
  • Managed without a closed-loop record: minutes that note the metric without a decision and a corrective action do not carry the Managed level; the review has to drive change and the change has to be evidenced
  • Factor profile under-scoped: the External Assessor and the QA review pull factors from the same source data the assessment relies on, and an under-scoped profile triggers re-scoping rather than acceptance
  • Evidence pack stored across drives and tickets: the MyCSF submission expects per-requirement linkage, and a sprawling evidence trail multiplies the assessor effort and the QA clarification cycle

How HITRUST CSF maps to the other frameworks the same entity has to satisfy

Healthcare and regulated organisations rarely run a single-framework programme. HITRUST CSF is built to consolidate the underlying control set, but the buyer-facing artefacts usually still include HIPAA Security Rule attestation, an ISO 27001 certificate, a SOC 2 Type II report, and one or more sector frameworks alongside it. Mapping the underlying controls once, then projecting the evidence into each framework, is the only way to keep the artefact pack manageable.

  • HIPAA Security Rule (45 CFR Part 164 Subpart C): HITRUST CSF was originally built to operationalise HIPAA, and the Administrative, Physical, and Technical Safeguards under 164.308, 164.310, and 164.312 map directly to CSF control categories
  • ISO/IEC 27001 Annex A: the CSF references the ISO Annex A control catalogue and most r2 assessments reuse ISO evidence with minor enrichment
  • SOC 2 Trust Services Criteria: an r2 validated assessment frequently sits alongside a SOC 2 Type II report; many CSF requirements share evidence with SOC 2 CC, A, and PI criteria
  • NIST SP 800-53 and SP 800-171: the federal control catalogues feed the CSF technical baseline; r2 in federal-leaning environments commonly inherits 800-53 evidence
  • PCI DSS: payment-handling subsystems in healthcare environments frequently have to satisfy PCI DSS alongside HITRUST; the requirement statements share evidence on access, key management, and logging
  • GDPR Article 32: the privacy practices category in the CSF picks up the technical and organisational measures expected under GDPR for entities processing EU resident data

For the cornerstone risk analysis that sits underneath every CSF programme in a healthcare environment, the HIPAA Security Rule framework page covers the 45 CFR Part 164 Subpart C structure that HITRUST CSF was originally built to operationalise. The NIST SP 800-53 and GDPR framework pages cover the federal and EU regimes the CSF inherits from for organisations operating across those environments.

Where SecPortal fits in the HITRUST CSF workflow

SecPortal is the operating layer for the HITRUST CSF programme, not a replacement for MyCSF or for the External Assessor. The platform handles scoping, scans, findings, control mapping, business associate records, incident timelines, and the assessor-ready output, so the work runs as a structured workflow rather than a long email thread. Compliance tracking covers HITRUST CSF alongside the other frameworks the same entity has to satisfy.

  • Compliance tracking that maps every finding to HITRUST CSF control categories alongside HIPAA Security Rule standards, ISO 27001 Annex A, SOC 2 Trust Services Criteria, NIST SP 800-53 control families, PCI DSS requirements, and GDPR Article 32 measures
  • Engagement management for HITRUST readiness, validated assessment, and bridge assessment work, with scope, status, evidence, and re-test on the same record
  • Findings management with CVSS 3.1 scoring, 300+ templates, and Nessus or Burp Suite imports, so existing tooling feeds the same control evidence without rekeying into the SSP
  • 17-module authenticated scanning that produces direct evidence for access control, audit, integrity, authentication, and transmission categories on the CSF technical side
  • 16-module external scanning and attack surface management for the internet-facing perimeter, with evidence retained per scan window for the Implemented and Measured PRISMA levels
  • Code scanning (SAST and SCA) for in-scope applications, feeding requirements under the secure development category with finding history and fix verification
  • Continuous monitoring with scheduled scans (daily, weekly, monthly) so the External Assessor and the QA review see active management rather than a snapshot
  • AI report generation that turns the readiness output, control assessment, and remediation status into board, External Assessor, and BAA-counterparty narratives without manual rewriting
  • Branded client portal for External Assessor firms delivering HITRUST work to multiple covered entities and business associates, so the deliverable looks as polished as the work behind it

Built for the External Assessor, the covered entity, and the business associate

HITRUST work touches three distinct audiences: the External Assessor firm running the validated assessment, the covered entity or business associate that owns the programme, and the BAA counterparty (or vendor risk team) consuming the certificate. SecPortal supports each of them on shared records, so handover does not become a re-keying exercise.

For consultants delivering HITRUST readiness and validated assessments to multiple covered entities and business associates, the security consultants workspace bundles the workflow with branded client portals and AI report generation, so the deliverable looks as polished as the work behind it. For internal compliance teams running CSF as part of a broader programme, the internal security teams workspace keeps the requirement-to-evidence linkage current across multiple frameworks.

For the operational work that produces the technical evidence the CSF requires, the vulnerability assessment workflow and the remediation tracking workflow keep the loop from finding to fix to verification on the same record. The third-party vendor risk assessment guide covers the BAA programme HITRUST CSF certificates feed into.

HITRUST CSF is a programme, not a project. The first cycle confirms the factor profile, completes readiness, closes the documentation gaps, and submits the validated assessment; the second cycle deepens the PRISMA Measured and Managed evidence and tightens the cross-framework mapping. Running the work as a managed workflow pays off most over time, because historical findings, remediation timelines, business associate records, and scoring history stay linked across cycles, so each interim review, bridge assessment, or BAA refresh is a refresh rather than a rebuild.

Key control areas

SecPortal helps you track and manage compliance across these domains.

e1, i1, r2: choosing the assessment type

HITRUST publishes three validated assessment types. e1 covers 44 controls focused on cybersecurity hygiene with a one-year certificate. i1 covers around 182 controls drawn from the leading practice baseline with a one-year certificate. r2 is the flagship risk-tailored assessment with a two-year certificate, an interim review at month 12, and a requirement count typically ranging from 200 to 2,000+ depending on the factor profile. 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.

Factor-based scoping and the requirement set selection

The CSF is tailored, not flat. Each engagement begins with a factor profile (organisational size, regulatory environment, system characteristics) that drives the requirement set selection in MyCSF. Two organisations certifying against the same framework can land at very different requirement counts because their factor profiles differ. Get the profile right and the assessment depth, the assessor effort, and the evidence pack the SSP has to support all sit at the right level.

The 14 CSF control categories

Requirements are organised into 14 categories: Information Security Management Programme; Access Control; Human Resources Security; Risk Management; Security Policy; Organisation of Information Security; Compliance; Asset Management; Physical and Environmental Security; Communications and Operations Management; Information Systems Acquisition, Development and Maintenance; Information Security Incident Management; Business Continuity Management; and Privacy Practices. Most r2 evidence is produced once and projected into the categories the requirement set actually exercises.

PRISMA maturity scoring: Policy, Process, Implemented, Measured, Managed

Each CSF requirement is scored across five PRISMA maturity levels. Policy and Process score documentation. Implemented scores production evidence drawn from configuration, scan output, screenshots, and access records. Measured scores defined metrics with collection cadence. Managed scores closed-loop review where measurement drives change. Documented-but-static controls plateau at Process or Implemented; programme-grade controls reach Measured and Managed.

Penetration testing and vulnerability management evidence

The CSF expects vulnerability scanning and, for environments above a threshold defined by the factor profile, penetration testing as part of the secure development and vulnerability management categories. The expectation is documented scope, recognised methodology (PTES, NIST SP 800-115, OWASP WSTG), CVSS-scored findings, remediation status per finding, and a re-test result before certification. Loose attestation language in place of evidence is read as a control gap by both the External Assessor and the QA review.

MyCSF, External Assessor, and HITRUST QA

A validated assessment is a multi-stage engagement: scoping, External Assessor selection, readiness, fieldwork, HITRUST QA review, certification, and (for r2) the interim review at month 12. The MyCSF platform holds the SSP, the requirement set, and the evidence linkage; the External Assessor scores per requirement; HITRUST QA validates the scoring before certification issues. Pack quality is the single biggest determinant of QA clarification volume.

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 requirements from ISO/IEC 27001, NIST SP 800-53, NIST SP 800-171, PCI DSS, GDPR, FISMA, and a wide range of state and sector regulations. Mapping the underlying controls once, then projecting the evidence into each framework, is the only way to keep the artefact pack manageable across the regimes a single entity has to satisfy.

Run a defensible HITRUST CSF programme without spreadsheet sprawl

Factor scoping, PRISMA-aligned evidence, scanner and pentest output, remediation tracking, and MyCSF-ready submissions in one workflow. Start your free trial.

No credit card required. Free plan available forever.