HIPAA Security Rule compliance checklist: what OCR expects

What a HIPAA Security Rule compliance checklist must cover

No HIPAA certificate exists, so the checklist below is what an OCR investigator or a customer's security reviewer will expect to see evidence for. The Security Rule is codified at 45 CFR Part 164 Subpart C, and its required items cover risk analysis and risk management, a named security official (45 CFR 164.308(a)(2)), written policies and procedures under 164.316(a), workforce security awareness and training under 164.308(a)(5), business associate assurances under 164.308(b), contingency planning, periodic evaluation under 164.308(a)(8), review of information system activity under 164.308(a)(1)(ii)(D), and six-year retention of documentation under 164.316(b)(2)(i). Treat each of these as a line item with an owner, a date and a file that proves it. The organization owns every control. An implementation partner can prepare the systems, policies and evidence, but only an independent assessor or auditor can report on whether the controls work.

Build the checklist from the rule text rather than from a vendor's questionnaire. Start with the risk analysis, because it drives the other decisions: a documented risk analysis tells you which safeguards are reasonable and appropriate, and OCR's audit and enforcement record repeatedly cites its absence. For each item, record who is accountable, where the evidence lives, when it was last reviewed and what the next review trigger is. Expect investigators to ask for the most recent version of each document, not a draft written after the request arrived. Confirm the retention period and storage location for each record with your counsel, because the six-year rule applies to documentation, not to every log or system export.

Addressable implementation specifications still require a decision. For each one, the checklist should show that you assessed whether it is reasonable and appropriate, implemented it or documented why not, and put an equivalent alternative measure in place where one is reasonable (45 CFR 164.306(d)). A blank cell or a line that says "not applicable" without reasoning is the gap assessors most often flag. Ask any consultant or tool vendor to show you where each addressable decision is recorded, and confirm with your own compliance lead that the rationale reflects your size, infrastructure, cost and risk profile. The full set of 36 specifications and their required or addressable status is set out in Appendix A to Subpart C, which the eCFR Appendix A matrix lists in full.

Which required items OCR looks for first

OCR investigators tend to start with the documents and records that show a covered entity or business associate has run the Security Rule's management processes. The cards below cover the items a reviewer can check quickly, and each one ends with a question you can answer with a document, a log or a named person.

Risk analysis and risk management

The accurate and thorough risk analysis under 164.308(a)(1)(ii)(A) is a required specification, and the risk management plan under 164.308(a)(1)(ii)(B) must reduce identified risks to a reasonable and appropriate level. Reviewers look for both documents and for a link between them. Check: does your risk analysis list every system holding ePHI, and does each high-rated risk have a dated treatment decision?

Named security official

Under 164.308(a)(2), the entity must identify one person responsible for developing and implementing the Security Rule policies and procedures. The role can be held by an employee or by an outside party under a written arrangement, but the entity still owns the decision. Check: can you name the security official, state the date of appointment, and show where that person's duties are written down?

Written policies and procedures

Section 164.316(a) requires reasonable and appropriate policies and procedures for every standard and implementation specification, scaled to your size, infrastructure, cost and risk. Reviewers compare what the policies say with what staff actually do. Check: does each policy name an owner, a review date and the Security Rule provision it implements?

Workforce training and sanctions

Section 164.308(a)(5) requires a security awareness and training program covering all workforce members, including management. Sanctions for violating policy are part of the same expectation, so a training record without a discipline process leaves a gap. Check: can you produce completion records for every workforce member, including executives, and a written sanctions policy that was applied to a past violation?

Business associate assurances

Under 164.308(b), a covered entity may let a business associate handle ePHI only after receiving satisfactory assurances, documented in a written contract or other arrangement. Subcontractors that the business associate uses carry the same expectation down the chain. Check: does every vendor that creates, receives, maintains or transmits ePHI for you have a signed agreement on file, and does that agreement cover subcontractors?

Contingency planning and its five specifications

The contingency plan standard in 164.308(a)(7) contains a data backup plan, a disaster recovery plan and an emergency mode operation plan, all required, plus testing and revision procedures and applications and data criticality analysis, both addressable. Reviewers test whether the plans work, not only whether they exist. Check: when did you last restore ePHI from backup and record the result, and does your criticality analysis rank each system that holds ePHI?

Periodic evaluation

Section 164.308(a)(8) requires a periodic technical and nontechnical evaluation that measures how well your policies meet the Security Rule, and a new evaluation when environmental or operational changes affect ePHI. A one-time assessment at implementation does not satisfy the standard. Check: is there a dated evaluation report, and does it cover a change that occurred since the last one, such as a new cloud service or a merger?

Information system activity review

The procedure under 164.308(a)(1)(ii)(D) requires regular review of records such as audit logs, access reports and security incident tracking reports. This is a required specification, and reviewers ask who reads the logs and what happens when they find something. Check: can you show a dated review of activity records, the reviewer's name, and the follow-up on any anomaly it found?

Six-year documentation retention

Section 164.316(b)(2)(i) requires keeping Security Rule documentation for six years from creation or from the date it was last in effect, whichever is later. Superseded policies, past risk analyses and old evaluation reports all count. Check: does your retention schedule keep every prior version of policies and assessments for six years after it was replaced, and can you retrieve them on request?

How addressable specifications change the checklist

Of the 36 implementation specifications in Appendix A to Subpart C, 22 are addressable and 14 are required. For the checklist, that means roughly six in ten items carry a decision step that many teams skip. Under 45 CFR 164.306(d), an entity must assess whether each addressable specification is reasonable and appropriate in its environment. If it is, the entity implements it. If it is not, the entity must document why and, where reasonable and appropriate, adopt an equivalent alternative measure. Addressable is not the same as optional, and an assessor will expect a written record for every addressable item, including the ones the organization decided to implement without difficulty.

Practically, each addressable line on the checklist needs three artifacts: the assessment, the decision and the evidence that the decision was carried out. The assessment should trace back to the risk analysis under 45 CFR 164.308(a)(1)(ii)(A), so the reasoning links a specific risk to a specific measure. Confirm with your security official which addressable items your environment touches, such as transmission security, encryption and decryption, or the automatic logoff and unique user identification settings in the technical safeguards. For each one, record who approved the decision, the date, and where the alternative control is configured or documented. A decision recorded only in an email thread is hard to defend during an OCR inquiry.

The proposed rule published January 6, 2025 (90 FR 898) would remove the addressable category and make nearly all specifications required, which would change this checklist substantially. As of October 2026, the current rule still applies, so the addressable decision records remain necessary. Teams preparing for the change can already flag which addressable items would become mandatory and check whether encryption, multi-factor authentication and asset inventories are in place. Ask your assessor or implementation partner to label those gaps separately so the current documentation and the future requirements stay distinct.

What each owner checks in the checklist

The executive owner is accountable for decisions that the Security Rule assigns to management: accepting residual risk, funding the safeguards that the risk analysis calls for, and naming the security official responsible for the policies and procedures. The rule does not require a particular title or reporting line for that role, so the executive owner's job is to make sure the appointment is written down and that the person named has the authority and budget to act. Under the required risk management specification, leadership should be able to show which risks were accepted, by whom, and why.

Security official appointment: A signed or minuted designation that names the individual responsible for Security Rule policies and procedures, with a stated date and scope.
Risk acceptance record: Decisions for each residual risk the organization chose to keep, showing who approved it and the reasoning.
Budget linkage: Evidence that remediation items from the risk analysis were funded, deferred or re-scoped, with a date for each decision.
Management training: Records showing that management is included in the workforce security awareness and training program.

Ask whether each of these records can be produced within a short window and whether they match what the risk analysis says.

How to work through the checklist from gap to evidence

This sequence moves an organization from an unclear picture of where ePHI lives to a set of dated, approved and tested records that an OCR investigator or independent assessor can review. Each step produces a specific artifact that the next step depends on.

Confirm scope and map where ePHI lives
Start by listing every system, application, device, cloud account and business partner that creates, receives, maintains or transmits electronic protected health information. Compliance, IT operations and the business owners of clinical and billing workflows should all contribute, because systems often hold ePHI in places no one documented, such as exports, backups and shared drives. The output is a scope statement and a data flow inventory that names each ePHI location and its owner. The step is done when every system on the inventory has an accountable owner and the security official has signed off on the boundary.
Run the enterprise risk analysis
Perform an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of the ePHI identified in the inventory. Threats, vulnerabilities, likelihood, impact and current safeguards should each be recorded for every system, using a method the organization can explain, such as the HHS risk analysis tool or the approaches described in NIST SP 800-66 Rev. 2. The output is a dated risk analysis report. It is complete when each identified risk has a rating and a named owner, and the report states its scope and assumptions.
Set the risk management plan
Turn the ranked risks into a risk management plan that describes which security measures will reduce each risk to a reasonable and appropriate level, who will implement them, and how progress will be tracked. Leadership should approve the plan and accept any residual risk in writing, since the rule places the decision on the entity rather than on a vendor. The output is an approved plan with owners, target states and a review cycle. The step is done when each high-rated risk maps to at least one measure or to a documented acceptance decision.
Document addressable specification decisions
Review each addressable implementation specification against the risk analysis. For every one, the entity must decide whether it is reasonable and appropriate to implement. If it is not, the rationale must be recorded and an equivalent alternative measure implemented where reasonable and appropriate. Legal, security and clinical leaders typically review these decisions together. The output is a decision log that links each addressable specification to its outcome, rationale and supporting control. The step is done when no addressable specification is left without a recorded decision.
Write and approve Security Rule policies
Write the policies and procedures that describe how the organization meets each standard and implementation specification, scaled to its size, infrastructure, cost and risk. Each document should name the role responsible for it and the systems it covers, and should reference the risk management plan and decision log. Senior management or the designated governance body should approve the documents, and the approval date and version should be recorded. The output is an approved policy set with a version history. The step is done when every standard in the checklist has at least one current, approved document.
Train the workforce and keep attendance records
Deliver a security awareness and training program to every member of the workforce, including management, and cover the policies that apply to each role. Sanctions for policy violations should be written into the program and communicated. Training completion, content versions and sanction procedures should be recorded so that they can be produced on request. The output is training records for each person, plus the course materials used. The step is done when the records show that current staff and new hires have been trained and that the sanctions policy has been distributed.
Put business associate agreements in place
Identify every vendor that creates, receives, maintains or transmits ePHI on the organization's behalf, and obtain satisfactory assurances from each before ePHI is shared. Those assurances must be documented in a written contract or other arrangement, and subcontractors that handle ePHI need the same protections in their own agreements. Legal and procurement should own the contract work, while the security official reviews the security terms. The output is a register of business associates with signed agreements and their review dates. The step is done when no vendor with ePHI access lacks a documented arrangement.
Test contingency and disaster recovery plans
Document the data backup plan, disaster recovery plan and emergency mode operation plan, then run tests that show the procedures work for the systems in scope. Testing and revision procedures and an applications and data criticality analysis are addressable specifications that should be decided in step four. Results should identify gaps, and the plans should be revised when the tests reveal them. The output is the plans, a test record with dates and results, and a list of corrective actions. The step is done when a test has been run, its findings are tracked, and the plans reflect the outcome.
Set up log review and run the periodic evaluation
Establish procedures to review audit logs, access reports and security incident tracking reports on a regular schedule, and record who reviewed them and what they found. Then carry out the periodic technical and nontechnical evaluation that measures how well the policies and procedures meet the rule, repeating it when environmental or operational changes affect ePHI. The evaluation should feed new actions back into the risk management plan. The output is a log review record and an evaluation report. Retain all Security Rule documentation for six years from creation or last effective date, whichever is later.

Which evidence proves each checklist item

This table pairs each core checklist item with its Security Rule citation, the evidence an assessor will ask for, and the party usually responsible for producing it. Read it as a preparation list: if a row has no dated, signed or logged artifact behind it, the item is not yet demonstrable. Ownership is the covered entity's or business associate's; outside partners may prepare evidence but do not issue findings.

Checklist item	Rule citation	Evidence an assessor will ask for	Usual owner
Accurate and thorough risk analysis	164.308(a)(1)(ii)(A)	Dated analysis covering all systems holding ePHI, with threats, vulnerabilities and likelihood ratings	Security official with executive sponsorship
Risk management plan	164.308(a)(1)(ii)(B)	Documented measures tied to each identified risk, with owners, target dates and residual risk notes	Security official and system owners
Named security official	164.308(a)(2)	Written designation showing the individual's name, role and authority over policies	Executive leadership
Written policies and procedures	164.316(a)	Approved, version-controlled policies with review dates and records of who approved them	Security official and compliance lead
Workforce training and sanctions	164.308(a)(5)	Training curriculum, attendance records for all workforce members including management, and sanction policy with applied cases	HR and security awareness owner
Business associate agreements	164.308(b)	Signed written contracts or arrangements for each business associate, with subcontractor flow-down terms on file	Legal and procurement, with privacy or security input
Contingency and backup plans	164.308(a)(7)	Data backup, disaster recovery and emergency mode plans, plus restore test results and revision history	IT operations and platform engineering
Periodic technical and nontechnical evaluation	164.308(a)(8)	Dated evaluation report, scope statement and a list of follow-up actions triggered by environment changes	Security official, with independent reviewers optional
Activity review of system records	164.308(a)(1)(ii)(D)	Documented review procedure and dated review logs for audit trails, access reports and incident tracking	Security operations team
Six-year documentation retention	164.316(b)(2)(i)	Retention schedule and evidence that documents from the last six years are stored and retrievable	Records management and security official

Which gaps delay audits and OCR reviews

What happens when a HIPAA risk analysis is missing or out of date?

A missing or stale risk analysis is usually the first finding an investigator raises, because the rule requires an accurate and thorough assessment of risks to the confidentiality, integrity and availability of ePHI. Close it by inventorying every system that creates, receives, maintains or transmits ePHI, including cloud services and backups, then rating threats and vulnerabilities against each. Record the results, the risk management plan and the date. Update it after material changes such as a new EHR module, a cloud migration or a reorganization. The HHS guidance on risk analysis and the free HHS SRA Tool can structure the work, and NIST SP 800-66 Rev. 2 lists sample questions. Confirm with your own assessor whether your documentation shows a current, complete picture.

How do I document addressable specification decisions so they hold up?

Every addressable implementation specification needs a recorded decision. For each one, document whether it is reasonable and appropriate in your environment, and if it is not, why not, along with the equivalent alternative measure you chose if one is reasonable and appropriate. Tie each decision to the risk analysis so the reasoning is traceable. Undocumented decisions are common, and reviewers treat them as if no decision was made. Keep the records with your other Security Rule documentation and review them when the risk analysis changes. Confirm the exact wording against 45 CFR 164.306(d) with counsel before you finalize the template.

Does a named security official need more than a name on paper?

Yes. The rule requires you to identify the security official responsible for developing and implementing the Security Rule policies and procedures, and reviewers check whether that person actually holds the responsibility. A name alone does not show that the role has authority, time or a working set of policies behind it. Give the official a written job description, a reporting line to leadership, budget for remediation and a record of decisions, such as signed policy approvals and risk treatment choices. If you outsource the role, the contract should state who signs what and who answers questions during an audit. Your organization still owns the outcome.

Which business associate agreement gaps cause the most trouble?

The most common gap is a business associate that subcontracts ePHI work without flowing the same safeguards down to the subcontractor. A covered entity may let a business associate handle ePHI only after satisfactory assurances are documented in a written contract or other arrangement. Check that every BAA is signed, current, and covers each service that touches ePHI, including hosting, support, backup and billing. Then confirm that each business associate has written agreements with its own subcontractors. Keep a register of vendors, their services and the date each agreement was last reviewed. Your counsel should confirm the required clauses.

How do I prove backups and disaster recovery actually work?

Written backup and disaster recovery plans are not enough on their own, because the rule expects the contingency plan to be workable. The data backup plan, disaster recovery plan and emergency mode operation plan are all required, and testing and revision procedures are addressable. Reviewers look for evidence that restores were tested, that results were recorded and that the plan changed after failures. Run restore tests on a schedule, time them against your stated recovery goals, and keep logs of what was restored, what failed and what you fixed. Run emergency mode drills that cover loss of your primary site or identity provider. Confirm with your vendors what their backup and restore terms guarantee.

What six-year records do auditors expect to see?

Auditors expect Security Rule documentation retained for six years from the date it was created or the date it last was in effect, whichever is later. The rule makes this retention a required specification. Gaps appear when teams keep current policies but discard earlier versions, risk analyses or training records. Use a document management system with version history, retention settings tied to the six-year rule, and access controls. Store policy revisions, risk analyses, sanctions records, training completion, BAAs and incident logs together. Confirm your retention schedule with counsel, especially where other laws require longer periods.

Can we do this in-house, or do we need an outside firm?

Most organizations can do much of this in-house, but the decision depends on capacity, expertise and how much evidence work remains. The Security Rule does not require outside help, and it does not require a certificate. Internal teams often own policies, training and record keeping, while outside partners help with system hardening, evidence collection and testing. A fixed-scope engagement works well when a single gap, such as a restore test or a risk analysis refresh, has clear deliverables. Ask any provider which parts they prepare and which parts you must own. Only independent assessors issue reports, so an outside partner cannot tell you that you are compliant.

Who does what: your team, an implementation partner, and the assessor

Your organization remains accountable for the Security Rule. No outside party can accept the risk on your behalf, make the risk analysis decisions the rule assigns to you, or designate your security official. The Security Rule requires a named security official responsible for developing and implementing the policies and procedures (45 CFR 164.308(a)(2)), and that person must be someone inside your organization who can make decisions and be held to them.

Security official: Name the individual, document the appointment, and give them the authority and budget to act.
Risk analysis and risk management: Own the scope, the threat and vulnerability decisions, and the risk acceptance for each finding. Outside help can draft these, but the decisions are yours.
Addressable specifications: Decide, document and justify each choice to implement, implement an alternative, or not implement, based on your risk analysis.
Workforce and sanctions: Run training for all workforce members, including management, and apply and record sanctions.
Business associate oversight: Obtain satisfactory assurances and review vendor evidence before ePHI is shared.

Confirm which of these tasks your current staff can perform without outside support before you scope any engagement.

How to choose a partner or assessor for the checklist

Outside help can prepare your Security Rule evidence, but it cannot make your organization compliant or issue a HIPAA certificate. The cards below cover the checks that separate a useful partner from one that creates risk, starting with independence and ending with the questions to put in writing before you sign.

Confirm independence from the work

Ask whether the firm that runs your risk analysis, writes your policies or operates your systems is also the one testing or reviewing them. A reviewer who built the controls is grading its own work, and OCR investigators will ask who did what. Get a written statement naming any product resale, managed service or referral arrangement that could influence findings. Separate the preparer from the assessor where you can, and record which party owns each deliverable.

Check healthcare and HIPAA experience

Ask for examples of Security Rule work in organizations like yours, such as a small practice, a health plan or a business associate hosting ePHI. Request the names of the standards they have worked through, not just a count of engagements, and ask how they stay current with OCR guidance and the pending proposed rule. Confirm that the people doing the hands-on work, not only the sales lead, have this background. Do not accept a general cybersecurity résumé as a substitute for HIPAA knowledge.

Use NIST SP 800-66 Rev. 2 as the reference

NIST SP 800-66 Rev. 2, published in February 2024, is a resource guide that gives key activities and sample questions for each Security Rule standard. HHS lists it as informational rather than legally binding. Ask the partner to map its approach and deliverables to that guide, and to explain where it departs from it and why. A firm that cannot explain the guide, or that treats it as a checklist of legal requirements, is a warning sign.

Require a written fixed scope

Ask for a scope document that lists the systems, locations, business associates and standards in play, the deliverables with their formats, and the dates on which they will be delivered. State who provides what evidence and who signs off on acceptance. Most engagements are fixed-scope, and a quote should follow directly from that written scope. Be cautious of open-ended hourly arrangements for a first-time readiness project, because the cost of changes is then unpredictable. Confirm how updates to the scope are priced and approved.

Confirm who issues what

The partner prepares your systems, policies, risk analysis and evidence, but your organization owns its controls and its compliance position. Only an independent assessor can issue an audit report or attestation, and HHS does not recognize private HIPAA certificates. Ask the partner to state in writing that it will not issue or imply a certification, and ask any third-party assessor what its report does and does not cover. Make sure the contract says who holds the final documentation and who is responsible for retention.

Ask these questions before signing

Before you sign, ask how the partner will handle PHI it sees during the work, whether it will sign a business associate agreement with you, and who holds the data and the evidence at the end. Ask what happens if OCR requests records, how the firm documents its own findings and what its conflict-of-interest process covers. Request two or three references from comparable organizations, and confirm the names of the people who will do the work. Record every answer in the contract or statement of work.

How long, how much effort and can we do it ourselves

Is HIPAA certification required to prove Security Rule compliance?

No. No Security Rule standard requires an entity to certify compliance, and HHS does not endorse or recognize private HIPAA certifications. What you can do is show evidence: a documented risk analysis, written policies, training records, business associate agreements and activity reviews. Some customers ask for a third-party assessment report, but that report reflects the assessor's work at a point in time, not an official HHS credential. Ask any assessor exactly what their report covers and what it does not.

What drives how long HIPAA Security Rule work takes?

The main driver is scope: how many systems hold or transmit electronic PHI, how many locations and vendors touch it, and how much of the risk analysis and policy set already exists. An organization with a current risk analysis and mapped ePHI flows usually has a shorter path than one starting from no inventory. Ask for a written project plan with phases, dependencies and the staff time each phase needs. Any duration in a quote should be tied to that scope, not offered as a general promise.

What effort will our staff need to put in?

Expect time from the security official, system owners, HR for training and sanctions, legal for business associate agreements, and leadership for risk decisions. The security official role is required by 45 CFR 164.308(a)(2), so a named person must own policies and procedures even if an outside party does much of the preparation. System owners will need to confirm configurations, access lists and backup status. Ask the partner to list each role, the decisions it must make and the hours it should expect to spend.

Can our internal team complete HIPAA Security Rule compliance alone?

Many organizations can do much of the work internally, especially when they have security staff who understand the rule and the time to maintain it. The rule allows measures scaled to size, infrastructure, cost and risk under 45 CFR 164.306(b)(2), so internal teams have room to choose. The hard parts are an accurate risk analysis, consistent documentation and keeping records current. Free resources such as the HHS SRA Tool and NIST SP 800-66 Rev. 2 can support internal work, though neither replaces professional judgment.

What recurring work does HIPAA Security Rule compliance require each year?

Several obligations repeat or must stay current. The risk analysis must be updated as the environment changes, and the periodic evaluation under 45 CFR 164.308(a)(8) must be repeated in response to operational changes. Activity review under 45 CFR 164.308(a)(1)(ii)(D) is ongoing, training must reach the workforce, and business associate agreements need upkeep. Documentation must be kept for 6 years from creation or last effective date, whichever is later, under 45 CFR 164.316(b)(2)(i). Budget for these recurring tasks as well as the initial build.

What does getting it wrong cost compared with the work itself?

Penalties are assessed per violation and vary by culpability. For penalties assessed on or after January 28, 2026, the inflation-adjusted civil money penalty for violations on or after February 18, 2009 ranges from $145 per violation with no knowledge to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294, according to 45 CFR 102.3 as amended at 91 FR 3666. Settlements also carry corrective action plans and monitoring costs. Use these figures to frame the value of an accurate risk analysis, not to predict any single outcome.

What should we ask for in a quote for HIPAA Security Rule work?

Ask for a written scope that lists the systems, locations, business associates and standards covered. A useful quote separates one-time work, such as the risk analysis, policy set and configuration changes, from recurring work, such as annual evaluation, training and monitoring support. It should name who performs each task, what evidence will be delivered, what the organization must provide, and what is excluded. Confirm that the partner prepares evidence and does not issue attestations or reports, which only an independent assessor can do.

Which parts should we outsource and which should we keep in-house?

Keep ownership of decisions that belong to the organization: accepting residual risk, naming the security official, approving policies and signing business associate agreements. Outside help is often useful for the risk analysis method, technical configuration hardening, evidence collection and testing. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside a client's own infrastructure, and runs security testing, but it does not issue audit reports or certifications. Confirm the split in writing before work starts.

How DeployOpen prepares HIPAA Security Rule evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the systems behind your HIPAA Security Rule checklist can produce the records an assessor will ask for. We prepare systems, controls and evidence; your organization owns its controls, and only an independent auditor or assessor issues reports.

How we scope

Each engagement starts with a written scope listing the ePHI systems, checklist items and environments covered.
Scope names the checklist evidence we will prepare, such as risk analysis inputs, log review records and contingency plans.
Scope also states what remains with your security official, workforce training and business associate contracts.

How we build

We configure self-hosted platforms in your cloud accounts, data centers or air-gapped networks to meet agreed safeguards.
We set up audit logging, access reporting and backup and recovery procedures so records exist before an assessment begins.
Security testing of applications, APIs and infrastructure is run against the agreed scope and findings are tracked to closure.

How we hand over

You receive documentation mapping each checklist item to the system configuration, procedure or record that supports it.
Runbooks cover backup, disaster recovery, emergency mode operation and log review so your staff can operate the environment.
Handover includes a list of items you must confirm yourself, including policies, sanctions and the periodic evaluation.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can keep log review, backup verification and checklist documentation current as systems change.
Assessment-readiness support prepares evidence for your auditor, while the auditor alone reports on your compliance.