Can a SOC 2 report replace HITRUST testing for a third party?
When a customer or contract requires HITRUST and your platform depends on cloud or service providers that already hold SOC 2 reports, the practical question is whether the External Assessor can rely on those reports instead of testing the providers directly. The answer is yes, but only under strict conditions. An External Assessor may rely on a SOC 2 Type II report only if it is final, independent, no more than one year old at the start of HITRUST fieldwork, shareable with HITRUST, overlaps the assessment's scope and controls, and is mapped to the relevant requirement statements. A SOC 2 Type I does not qualify, because its procedures lack the substantive testing the assessor needs to lean on.
You own your controls, and the assessor alone decides whether reliance is acceptable and issues the HITRUST result. An implementation partner such as DeployOpen can help you map the provider's SOC 2 criteria to the requirement statements in scope and assemble the supporting evidence, so the assessor has something concrete to review. That preparation does not make the mapping accepted. Confirm early with your External Assessor which mapping format and evidence they expect, and check the report's period, bridge letter coverage and carve-out language against the assessment's scope before you commit to a reliance approach.
The answer changes with the provider, the report period and the scope of your assessment. A provider's SOC 2 Type II may cover a service you do not use, or it may exclude the systems that handle your data. Its report period may end long before fieldwork starts, which the one-year limit measures from the end of the period to the start of fieldwork. Ask each provider for its current report, its subservice organization list and any exceptions it noted, then decide per provider and per assessment whether reliance, inheritance or direct testing is the right route.
Which six tests decide whether a SOC 2 report counts
An External Assessor does not accept a third party's audit report on trust. Each report must pass a set of tests before the assessor can rely on it in place of direct testing. The six cards below cover those tests in the order most assessors work through them, with the evidence to hold and the failure that catches teams most often.
Final report
The assessor checks that the report is issued in final form, signed by the CPA firm, and not a draft or a readiness output. Hold the signed report and the full document, including the system description and the auditor's opinion, not a summary or a slide. The most common failure is relying on a draft or a management presentation that looks like a report but was never finalized. Confirm with the assessor which versions they will accept before you request the report.
Independence of the auditor
The assessor checks that the CPA firm issuing the report is independent of the organization being assessed and of the provider being relied on. A report issued by a firm that also built or operated the controls it tests raises questions about objectivity. Keep a record of who engaged the auditor and confirm that no advisory role creates a conflict. Ask the assessor how they handle a firm that performed both readiness work and the attestation.
Age at fieldwork start
For a period-of-time report such as a SOC 2 Type II, the one-year limit is measured from the end of the report period to the start of HITRUST fieldwork, not from the date the report was issued. A report that was current when signed can fall outside the limit by the time fieldwork begins. Calendar the report period end date against your planned fieldwork window, and request a bridge letter early if a gap is likely.
Shareable with HITRUST
The assessor must be able to share the report with HITRUST during central quality assurance. Some auditor agreements or provider contracts restrict distribution to named parties only. Check the report's distribution language and the provider's terms before you commit to the assessment plan, and get written permission where the wording is unclear. A report the assessor cannot pass to HITRUST cannot support the submission.
Scope and control overlap
The assessor checks that the systems, services and controls covered by the report overlap the scope of your HITRUST assessment. A report on a provider's data center does not cover your application layer, and a report on one product line does not cover another. Map the report's system description against your in-scope systems and list any gap in writing. Most failures come from assuming the report covers a service the provider only partly delivers.
Mapping to requirement statements
The assessor checks that each control in the report can be mapped to the specific HITRUST requirement statements it is intended to support. Mapping is a documented link, not a general claim that both frameworks cover access control. Build the mapping per requirement statement, record which report control and test procedure supports it, and note where the report's tests do not reach the requirement's depth. Unmapped statements fall back to direct testing or another reliance route.
Why a SOC 2 Type I does not qualify for reliance
A SOC 2 Type I report cannot be relied on in a HITRUST assessment. The HITRUST Assessment Handbook says that procedures in a SOC 2 Type I should not be relied on, and the reason is structural: a Type I describes whether a provider's controls were designed appropriately and in place at one point in time, without testing whether they operated consistently over a period. A HITRUST External Assessor needs evidence that a control worked across time, so a Type I leaves the assessor with a description of intent rather than proof of operation. If your provider has only a Type I, treat its report as background context for your readiness work, not as a source of coverage for any requirement statement.
The second rule concerns whose report you rely on. The Handbook calls relying on a SOC 2 Type II for a provider the entity does not actually use inappropriate, so the report must belong to a third party that supports your in-scope environment. Before the assessor accepts any Type II, confirm that the provider named in the report is the same entity, and the same service, that processes or hosts your data, and that the report's scope covers the systems and controls you are relying on. A report for a sister company, a different product line or an unused service does not transfer coverage, however current it is. *Illustrative example:* a SaaS platform's hosting provider gives you a SOC 2 Type I dated six months ago. Your assessor cannot rely on it, so for the hosting-related requirement statements the assessor will test the provider's controls directly, typically through your own evidence requests, configuration exports and sampled records. Ask the provider early whether a Type II covering the same services is available, and check its period and scope against the rules in the main section above.
How the one-year age limit is measured for a SOC 2 Type II
This sequence shows how a period-of-time SOC 2 Type II report moves from the end of its audit period to the start of HITRUST fieldwork, so you can confirm early whether the report is still usable for your e1 or other validated assessment.
Confirm the report period end date
The SOC 2 Type II covers a defined period of time, and that period has a fixed end date set by the service auditor. Your team reads the report's stated period and records the end date in your assessment file. This end date is the starting point for the age calculation, so it matters more than the date the report was signed. The check is complete when the period end date appears in your readiness workbook alongside the report's scope description.
Record the report issue date
The service auditor issues the report after the period closes, and the issue date is usually later than the period end. Your compliance lead notes the issue date separately, because it explains the timeline to the assessor but does not start the one-year limit. Keep the signed report, not a draft or a bridge letter, as the version you will later share. The step closes when both dates are recorded and you have confirmed the report is final.
Obtain and share the report with the assessor
Your organization requests the report from the provider, or holds its own report if you are the audited entity, and shares the complete document with the External Assessor. The assessor needs to confirm the report is shareable with HITRUST and that its scope overlaps the in-scope systems and controls. Your team confirms in writing that the assessor has received the full report, including the auditor's opinion and system description. The step closes when the assessor acknowledges receipt.
Set the fieldwork start date in the plan
The External Assessor sets the start of validated assessment fieldwork in the assessment plan. This is the date the assessor begins testing, and it is the second date that drives the age calculation. Your team should ask the assessor for the planned fieldwork start in writing, because a later start pushes the age of the report further from the period end. The output is a fieldwork start date recorded in the plan that you can check against the report period.
Measure the gap against the one-year limit
The assessor measures the interval from the end of the report period to the start of HITRUST fieldwork and checks that it does not exceed one year. Your team can run the same calculation before fieldwork begins, which shows whether the report can be relied on or whether another route is needed. If the interval is over the limit, the reliance is not available for that report. The output is a documented result for each report, either acceptable or outside the limit.
Document any gap explanation
When a period of time has passed between the report period end and today, the assessor may ask for documentation explaining the gap or confirming the provider's current control state. Your team collects any provider correspondence, change logs or interim statements that show the controls in scope continued to operate. Confirm with your assessor how bridge letters are treated for any gap between the report period and the present day, since handling can differ. The output is a file note the assessor can review alongside the report.
Confirm fieldwork runs within the window
Validated assessment fieldwork is limited to a window of at most 90 days for e1, i1 and r2 assessments. Your team agrees the window with the assessor and tracks when fieldwork begins and ends, so the start date used in the age calculation is the one actually followed. If fieldwork extends or restarts, the start date may change and the age calculation should be rechecked. The step closes when the assessor's plan and your records show the same fieldwork start and end dates.
Reliance, inheritance, internal assessors or direct testing: which fits
This table compares the four ways HITRUST recognizes for covering an in-scope third party, including reliance on a SOC 2 Type II. Read each column to see when an option fits, what evidence it needs, who makes the call and what happens if the option is not available.
| Option | When it fits | Evidence needed | Who decides and what if unavailable |
|---|---|---|---|
| Rely on a third-party audit report | The provider holds a current SOC 2 Type II or similar period-of-time report that overlaps your scope and is mapped to the requirement statements | A final, independent report no more than one year old at fieldwork start, shareable with HITRUST, with mapping to the relevant requirements | The External Assessor decides whether reliance is allowed. Without a qualifying report, the requirement is scored not compliant for that party |
| Inherit validated HITRUST results | The provider holds its own HITRUST validated assessment that covers the requirements you need | The provider's validated assessment results and a request made through the inheritance process | The provider and your assessor confirm eligibility. Without eligible results, the requirement falls back to another option or is scored not compliant |
| Rely on your internal assessors | Your own qualified internal assessors can test the third party's controls and you can document the work | Documented internal assessment procedures, sampled evidence and results that meet the assessor's review | Your External Assessor decides whether the internal work is acceptable. Without it, the requirement is scored not compliant for that party |
| Test the third party directly | No qualifying report or HITRUST result exists, or the report does not overlap your scope or controls | Your assessor's own testing of the provider's controls within the assessment fieldwork | Your External Assessor performs the work within the fieldwork window. Without it, the requirement is scored not compliant for that party |
| SOC 2 Type I report | Only a point-in-time SOC 2 Type I exists for the provider | Not usable as reliance evidence for procedures, because it lacks substantive testing | Treat as unavailable for reliance. Consider one of the other three options instead |
| SOC 2 Type II for a provider you do not use | A report exists for a vendor that is not the provider in your environment | Not applicable, because the report must cover the provider you actually use | Not acceptable as reliance. Confirm the report covers your provider and your services |
| Confirm the report age | A period-of-time report is nearing the one-year limit before fieldwork | Dates showing the end of the report period and the planned start of fieldwork | Confirm with your External Assessor early. Reports older than the limit cannot be relied on, so plan a bridge or direct testing |
| Confirm the report scope | The provider's report covers some but not all of the services you use | A scope comparison showing which systems, services and controls the report covers | Your External Assessor and provider agree the overlap. Uncovered areas need another option |
Who decides reliance, who prepares the evidence and who issues the result
The organization remains accountable for its own HITRUST assessment and for every third party in its scope. Before anyone relies on a provider's SOC 2 Type II report, the organization has to own the vendor due diligence that makes the report usable: it must know which services the provider delivers, which systems and data fall inside the organization's assessment scope, and whether the report covers those same services over a recent period. It also has to obtain the report itself and confirm it can be shared with the External Assessor and with HITRUST. That sharing right usually sits in the vendor contract or the provider's NDA, so the organization should check it before the assessment starts, not during fieldwork.
- Vendor due diligence: Decide which third parties are in scope and which ones the SOC 2 report would cover.
- Report acquisition: Request the current final report and any bridge letter covering the gap to the fieldwork date.
- Sharing rights: Confirm the contract allows disclosure of the report to the External Assessor and HITRUST.
- Complementary controls: Identify the user entity controls listed in the report and document how the organization meets them.
- Ongoing monitoring: Track the report's age so it does not lapse before fieldwork.
Check whether your contracts already give you these rights before you request a report, because renegotiating them mid-assessment is slow.
An implementation partner prepares the mapping and evidence that the External Assessor will later examine. For a SOC 2 report, that means mapping the report's criteria to the HITRUST requirement statements they touch, recording where the provider's controls cover those statements and where gaps remain, and documenting how the report's scope overlaps with the organization's assessment scope. The partner organizes this evidence so the assessor can trace each claim back to a source. This work is preparation only. The partner does not decide whether a report can be relied on, does not score requirement statements, and does not issue any report, letter or certificate.
- Criteria mapping: Prepare a working map from SOC 2 criteria to HITRUST requirement statements, marked as draft for assessor review.
- Gap identification: List requirement statements the report does not cover and note where direct testing or another source will be needed.
- Scope overlap records: Document systems, services, locations and periods the report covers against the organization's scope.
- Evidence organization: Collect and index the report, bridge letters, contract clauses and vendor correspondence so they are easy to test.
- Independence boundary: Keep every mapping labeled as the organization's preparation, not as a conclusion about reliance.
Ask any partner to show you the mapping template and confirm in writing that it will not make reliance decisions.
Only an Authorized HITRUST External Assessor organization can perform the validated assessment submitted for certification. The assessor decides whether a third party's audit report may be relied on, based on the rules in the HITRUST Assessment Handbook: the report must be final, independent, no more than one year old at fieldwork start, shareable with HITRUST, overlapping in scope and controls, and mapped to the relevant requirement statements. Where a SOC 2 Type I or an inappropriate report fails these tests, the assessor tests the requirement directly or the requirement is scored not compliant for that party. After fieldwork, the assessor submits the assessment to HITRUST, and HITRUST performs central quality assurance before any report is issued.
- Reliance decision: Accept or reject each report for each requirement statement, with reasons recorded.
- Direct testing: Test the requirements where reliance fails, using sampling and procedures from the Handbook.
- Fieldwork window: Complete validated fieldwork within the window the Handbook allows, which is at most 90 days.
- Submission: Submit the completed assessment to HITRUST for central quality assurance.
- Issuance: HITRUST issues the report only after its quality assurance, so no party in the organization or partner chain can issue it.
Ask your assessor, before fieldwork, which reports it expects to rely on and which requirements it will test directly.
How scope overlap and mapping work for a SOC 2 report
A SOC 2 report only helps with the systems it actually describes. The report covers the provider's system description and the Trust Services Criteria the provider selected for that examination, and those two things often differ from the systems and requirements in your HITRUST assessment. Before an External Assessor relies on a report, overlap has to be shown system by system and control by control. Pull the system description and list each component, application, environment and location it names. Then compare that list against the in-scope systems in your HITRUST scope statement. Any in-scope system the report does not describe, or describes only in part, must be tested another way or covered by a different reliance route.
Mapping is the link between a SOC 2 control and a HITRUST requirement statement, and the assessor decides whether that link holds. A mapping shows which SOC 2 control evidence speaks to which requirement statement, and whether the control's design and operating period actually address what the requirement asks. Published crosswalks between frameworks are useful starting points, but none should be treated as authoritative for a HITRUST assessment. Ask your External Assessor in writing which mapping they accept, whether they want a mapping at the level of individual requirement statements, and how they will document it in the validated assessment. Agree on that format before fieldwork so you are not rebuilding the mapping during the assessment window.
Check how the SOC 2 report treats subservice organizations and carved-out functions before you rely on it. If the report uses the carve-out method for a hosting or data center provider, the controls at that provider are outside the report, and the in-scope systems that depend on them are not covered by it. If the report uses the inclusive method, confirm which subservice controls were tested and whether they match the components your scope names. Ask the assessor how they will cover any gap, and confirm the provider's report period and the exact list of systems it covers before you start, since a mismatch found during fieldwork can delay the assessment.
How SOC 2 work can feed an e1 assessment
An organization with a recent SOC 2 Type II already has a body of tested evidence: access reviews, change records, incident logs and monitoring samples gathered over an observation period. That material is valuable starting point for an e1, because many of the operational controls it covers also appear among the e1 requirement statements. Reusing it still requires mapping each piece to the specific requirement statements, since a SOC 2 criterion is not a one-for-one match with an e1 requirement. The SOC 2 report itself does not satisfy any e1 requirement.
- Reusable evidence: Access review records, change tickets and vulnerability scan results can often be reused if they fall inside the e1 scope and period.
- Control descriptions: The system description and control narratives give the assessor a head start on how controls operate, but they must be rewritten to match e1 wording.
- Remaining gaps: The e1 requires specific control coverage across its 44 requirement statements (in v11.9), some of which a SOC 2 may not address at the same depth.
- What the e1 adds: A defined control set, testing by an authorized External Assessor and central HITRUST quality assurance before a report is issued.
- Scope and currency: Confirm the SOC 2 scope matches the e1 scope and that evidence is current at fieldwork.
Check which SOC 2 criteria map to which e1 requirement statements before deciding how much evidence you can reuse.
A SOC 2 Type I describes controls as designed at a single point in time without testing their operation over a period. That makes it a useful design document but weak evidence of operating effectiveness. The organization can reuse the system description, policy set and control design narratives as drafting material, but should not expect an assessor to rely on the Type I's procedures. The HITRUST Assessment Handbook states that procedures in a SOC 2 Type I should not be relied on because of the lack of substantive testing.
- Reusable material: Written policies, control narratives and system boundary descriptions can speed up e1 documentation.
- Operating evidence gap: Most e1 requirement statements need evidence that controls ran, such as logs, reviews and tickets, which a Type I does not supply.
- Assessor testing: The External Assessor tests the e1 controls directly, so the Type I's test results do not substitute for that work.
- Defined control set: The e1 uses a fixed set of requirement statements, while the SOC 2 Type I used criteria chosen by the organization and its CPA.
- Next step: Operating a control long enough to produce dated evidence is usually the largest effort beyond the Type I.
Confirm with your readiness adviser how much operating history your e1 scope requires before you start fieldwork.
An organization with neither a SOC 2 Type I nor a Type II starts with the e1 requirement statements as the planning baseline. The advantage is that the e1 defines a clear control set, so there is no need to reconcile an attestation's criteria against HITRUST wording. The work begins with a gap analysis of current controls against each requirement statement, followed by building and operating the missing controls. No SOC 2 report is needed to pursue an e1, though one may still be useful for customers who ask for it.
- Gap analysis: Compare existing policies, tools and records against the 44 e1 requirement statements in v11.9.
- Evidence build: Create the logs, reviews and records the assessor will sample, and allow time for them to accumulate.
- Defined control set: The e1 scope is fixed, so the work is bounded in a way an open-ended SOC 2 scope is not.
- Independent testing: An authorized External Assessor tests the controls, and HITRUST performs central quality assurance before issuing a report.
- Contrast with i1: The i1 is a certification with a defined control set and external testing, while a SOC 2 is an attestation with flexible criteria, so the choice between them depends on customer and regulator expectations.
HITRUST publishes resources on applying SOC 2 work toward an e1. Review them alongside the e1 assessment page before deciding whether a SOC 2 comes first.
What causes SOC 2 reliance requests to fail or stall
Most stalled reliance requests trace back to a handful of avoidable problems: stale reports, the wrong report type, mismatched scope, unresolved exceptions, contract limits and unagreed mappings. Each one is easy to catch early if the right person checks it before fieldwork begins.
Report aged past the limit
An External Assessor may rely on a period-of-time report only if it is no more than one year old when HITRUST fieldwork starts, measured from the end of the report period. A report that was current at signing can be outside the limit by the time fieldwork begins, which forces the assessor to test those requirements directly. Confirm the report period end date against the fieldwork start date, and check again if fieldwork slips. The compliance lead should own this check.
Type I offered in place of Type II
A SOC 2 Type I describes controls at a point in time and is not tested over a period, so the Handbook says its procedures should not be relied on. Requests built on a Type I usually stall at the first review and push the requirements back into direct testing. Ask the provider for the Type II covering a recent period, and confirm the assessor accepts that report type before the request is filed. The assessment lead should verify the report type on receipt.
Report does not cover the systems in scope
A report only helps if the systems, services and locations it examined overlap the systems and controls in your HITRUST scope. A provider's SOC 2 may exclude a region, a product line or a hosting component that your platform depends on. Compare the report's system description with your scope statement line by line, and list any gaps the assessor must test directly. The architect who wrote the scope should sign off on this comparison.
Exceptions touching in-scope controls
Exceptions noted in a SOC 2 report are findings the provider's auditor recorded, and they matter when they fall on controls you are relying on. An exception on access reviews or change management can disqualify the reliance for that requirement even when the overall opinion is clean. Read the test results section, not only the opinion, and record which exceptions touch your requirement statements. The security engineer responsible for each affected control should review them.
Contract blocks sharing with HITRUST
The report must be shareable with HITRUST, and many provider agreements limit distribution to the customer or to named parties. If the contract does not allow the report to go to the External Assessor or to HITRUST, the reliance cannot proceed, however strong the report. Review the confidentiality and third-party disclosure clauses before requesting the report, and ask the provider to confirm in writing that sharing with the assessor and HITRUST is permitted. The contracts or legal owner should check this early.
Mapping never agreed with the assessor
Reliance also requires that the report's controls are mapped to the HITRUST requirement statements. When that mapping is built after fieldwork starts, or is never reviewed by the assessor, the assessor may reject reliance for requirements they expected to accept. Agree the mapping format and the requirement statements in scope with the External Assessor during planning, and document which report sections support each mapped statement. The assessment lead and the External Assessor should agree this before fieldwork.
Questions buyers ask about SOC 2 reports in HITRUST
Does a SOC 2 Type II report always remove the need to test a provider?
No. A SOC 2 Type II can let an External Assessor rely on a provider's work for some requirement statements, but only when the report is final, independent, recent enough, shareable with HITRUST, overlaps your assessment's scope and controls, and is mapped to the specific requirement statements. Reliance is decided requirement by requirement, so a clean report can still leave gaps that must be tested directly or covered another way. Also confirm that the provider is one you actually use. Relying on a SOC 2 Type II for a provider your organization does not use is treated as inappropriate in the HITRUST Assessment Handbook, so a report from a vendor outside your service chain will not carry weight. Ask your External Assessor to confirm each condition before fieldwork begins.
What must we collect from a provider, and when?
Collect the provider's final SOC 2 report, its complete period of coverage, the system description and the list of controls the report covers, plus any bridge letter that explains the gap between the report period end and today. Request these before your readiness work starts, because mapping and scoping depend on them and providers can take time to release reports under their own confidentiality terms. Also collect written permission for the report to be shared with HITRUST and your External Assessor. Confirm early that the provider will supply its updated report when a new one is issued, since a stale report stops qualifying for reliance.
Can an implementation partner prepare the SOC 2 to HITRUST mapping?
Yes, an implementation partner can prepare the mapping work, but the organization owns the result and the External Assessor must accept it. A partner can compare the SOC 2 control descriptions and test evidence against HITRUST requirement statements, identify which statements the report covers, flag gaps and organize the evidence package. The organization must review the mapping against its own environment, because a report only covers the systems and controls the provider described. Your External Assessor independently decides whether the mapping supports reliance. Ask any partner to show how each mapped statement links to a specific report section and to confirm the scope overlap in writing.
How does the one-year age check work in practice, and what must we confirm?
For a period-of-time report such as a SOC 2 Type II, HITRUST measures the one-year limit from the end of the report period to the start of HITRUST fieldwork. The check is calendar based, so a report that was current at signing can age out before fieldwork begins if the assessment schedule slips. Confirm three dates: the end of the report period, the planned start of fieldwork and the date the assessor will test the report. Fieldwork itself is limited to a window of at most 90 days for e1, i1 and r2 assessments, so plan the timeline around both limits. Confirm the exact handling of your dates with your External Assessor or HITRUST, since the rules depend on your assessment type and timing.
Can a SOC 2 report feed an e1 assessment, and what remains?
A SOC 2 engagement can feed an e1 by providing evidence, control descriptions and test results that support e1 requirement statements. The e1 is a certification with a defined control set, external assessor testing and central HITRUST quality assurance, while a SOC 2 is an attestation with flexible criteria, so the two do not substitute for each other. What usually remains is the mapping to e1 statements, the testing that your assessor must perform directly, the evidence that reflects the e1 control set and HITRUST's own quality review. HITRUST publishes guidance on moving from SOC 2 to an e1, which is a useful starting point before you commit to a scope.
What can an implementation partner not do in a HITRUST assessment?
A partner cannot issue the HITRUST result, certify your organization, decide whether a SOC 2 report qualifies for reliance or submit an assessment as an External Assessor. Only Authorized HITRUST External Assessor organizations may perform validated assessments submitted for certification, and HITRUST performs central quality assurance before it issues reports. A partner can prepare systems, controls and evidence, support the mapping work, and help you respond to assessor questions. Your organization remains responsible for its controls and for the accuracy of what it shares. Before you engage anyone, confirm the assessor's authorization on HITRUST's external assessor directory and confirm the division of work in writing.
How much does it cost to rely on a SOC 2 report instead of testing?
Your cost depends on how many requirement statements the report can cover, the fee charged by your External Assessor and the effort needed to prepare the mapping and evidence. Reliance can reduce testing on covered statements, but the assessor still tests everything the report does not cover, and the mapping work is a recurring task each time a new report is issued. Ask your External Assessor for a quote that separates testing hours for covered and uncovered statements, and ask your SOC 2 provider how it charges for report copies and bridge letters. HITRUST does not publish a fee schedule for these items in the sources used here, so confirm current figures directly with the assessor or HITRUST.
How DeployOpen prepares SOC 2 evidence for HITRUST reliance
DeployOpen works on the evidence side of this question: we help organizations prepare self-hosted open-source platforms and their control records so that existing SOC 2 work can be presented to an External Assessor in a usable form. We do not issue SOC 2 reports, HITRUST certifications or reliance decisions, which remain with the CPA firm and the External Assessor.
How we scope
- Engagements are fixed-scope, with the in-scope systems, SOC 2 criteria and HITRUST requirement areas agreed in writing before work starts.
- We confirm which SOC 2 report, period and system description would be presented, and whether it covers the platform in question.
- The written scope states which mapping work is ours and which decisions stay with your CPA firm and External Assessor.
How we build
- We map the controls in your self-hosted platforms to the SOC 2 criteria and to the HITRUST requirement statements they may support.
- We configure logging, access reviews, change records and backup evidence so that the samples an assessor draws can be retrieved without rework.
- We identify gaps where SOC 2 testing does not reach a requirement, so you can plan direct testing or internal assessment instead.
How we hand over
- You receive a control-to-evidence mapping, documented procedures and a dated evidence index that your assessor can review.
- Deliverables include gap notes that state where a SOC 2 Type I, a Type II period or a missing mapping would limit reliance.
- Ownership of the documentation and configuration passes to your team, so the records stay usable at the next assessment.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, which helps keep the evidence current as the SOC 2 period moves forward.
- We can prepare updated evidence when the report age approaches the one-year limit for reliance, based on the agreed scope.
- Questions about whether an External Assessor will accept a specific report are best confirmed with that assessor early in the engagement.
