What HIPAA requires for on-premises ePHI systems
There is no HIPAA certification for on-premises systems, and no one else holds the physical safeguards for them. A covered entity or business associate that runs electronic protected health information (ePHI) in its own facilities owns every Security Rule obligation for those systems. The Security Rule is codified at 45 CFR Part 164 Subpart C and applies to covered entities and business associates for ePHI. When a cloud provider runs the hardware, that provider carries part of the physical burden under its contract. In your own data center or clinic, the organization carries all of it, including facility access under 45 CFR 164.310(a)(1), workstation safeguards under 164.310(c), and device and media controls under 164.310(d)(1). Backup and recovery sit in the administrative standards at 164.308(a)(7), where retrievable exact copies and data restoration procedures are both required implementation specifications.
Start by listing every physical location where ePHI is stored, processed or transmitted, including server rooms, wiring closets, imaging modalities, nurse stations and offices with workstations. For each location, confirm who holds keys or badges, how access is granted and removed, and how maintenance vendors are escorted. The rule asks for policies that limit physical access while still allowing properly authorized access, so document both sides. Workstation and device controls need the same inventory. Confirm which endpoints can reach ePHI, whether screens lock, and how laptops and removable drives are tracked from purchase to disposal. Several device and media specifications are addressable, not required. Disposal and media re-use are required, while accountability and data backup and storage are addressable (Appendix A to Subpart C).
For each addressable specification, the entity must assess whether it is reasonable and appropriate for its environment. If it is not, the entity must document why and implement an equivalent alternative measure where reasonable and appropriate (45 CFR 164.306(d)). Many on-premises teams skip this step, and an assessor will ask for the written decision. Record the reasoning, the date and the owner for each addressable item, such as whether an accountability log for hardware movement is reasonable for a small clinic. Then confirm the backup plan against the required restore procedures, and record restore test results in the same file. The HHS Security Rule guidance and the NIST SP 800-66 Rev. 2 resource guide list the safeguard activities and sample questions to check against.
Which physical safeguards you own on-premises
When ePHI systems run in your own facilities, no cloud provider shares the physical safeguards with you. The four areas below are the physical standards in 45 CFR 164.310 that you must design, operate and evidence yourself, and each one has a distinct requirement type and a distinct set of records an assessor will ask for.
Facility access controls
Section 164.310(a)(1) requires written policies to limit physical access to electronic information systems and the facilities that house them, while still allowing properly authorized access. Its implementation specifications are contingency operations and facility security plan, access control and validation, and maintenance records, and the Appendix A matrix marks them addressable, so you must assess each one, decide whether it is reasonable and appropriate, and document the result. An assessor will ask for the facility security plan, badge or key logs, visitor logs and the list of people with server room access.
Workstation physical safeguards
Section 164.310(c) requires physical safeguards for every workstation that accesses ePHI, restricting access to authorized users. This covers screen placement, locked rooms or cable locks, privacy screens in shared areas and automatic session locking for devices that sit in clinics, nurse stations or reception areas. Because the standard is a single requirement without separate specifications, assessors look for a documented workstation inventory and the physical controls applied to each location, not a generic policy statement.
Device and media disposal
Disposal under section 164.310(d)(2)(i) is a required specification. It requires procedures for final disposition of ePHI and the hardware or media it sits on, including disks, tapes, backup drives and printed output. HHS guidance treats media as secured when electronic media are cleared, purged or destroyed consistent with NIST SP 800-88, and paper is shredded or destroyed so PHI cannot be reconstructed. Ask for certificates of destruction, asset disposal logs and the sanitization method used for each media type.
Media re-use and sanitization
Media re-use under section 164.310(d)(2)(ii) is also required. Before a drive, server or removable device moves to another user or system, you must remove ePHI from it. Verify the wipe rather than assume it: keep a record of the tool, method and date, and check that re-issued hardware and shared test or lab systems are covered. Your procedures should name who signs off the re-use and where the record is kept, since an assessor will sample re-issued devices and ask for the matching log.
Accountability and data backup storage
Accountability under section 164.310(d)(2)(iii) and data backup and storage under section 164.310(d)(2)(iv) are both addressable. Accountability means keeping a record of hardware and media that move into, within and out of the facility, and the people responsible for them. Backup storage means deciding where retrievable copies live, how they are protected and who can reach them. Pair this with the required contingency specifications for exact copies and restoration, and show an assessor the movement log and an offsite or separate-room storage decision.
How media disposal and re-use must be done
Disposal and media re-use are both required implementation specifications under 45 CFR 164.310(d)(1), so an on-premises team cannot treat them as optional. Every drive, tape, backup appliance, copier hard drive and paper record that holds ePHI in your facilities needs a defined end-of-life path. HHS guidance on unsecured PHI treats destroyed paper as secured when it is shredded or destroyed so PHI cannot be reconstructed, and it specifically excludes redaction as a method. For electronic media, the HHS position is that they are secured when cleared, purged or destroyed consistent with NIST SP 800-88, *Guidelines for Media Sanitization*. Both NIST SP 800-88 and NIST SP 800-66 Rev. 2 are informational and not legally binding, but assessors use them as the benchmark for what a defensible method looks like.
Start by inventorying where ePHI sits on physical media in your own environment: server and workstation disks, SAN and NAS arrays, backup tapes, removable drives, imaging modalities, and devices that return from vendor repair. For each class, decide whether the media will be re-used internally, sold or donated, returned under a lease, or destroyed. Re-use requires a documented sanitization step before the device leaves the controlled area, and the sanitization method should match the media type, since overwriting suits some drives while others need cryptographic erase or physical destruction. Confirm the exact method with your own counsel and with any disposal vendor, and check that the vendor's contract addresses PHI handling and chain of custody.
The evidence trail is what an OCR investigator or independent assessor will ask for first. Keep disposal logs that list each asset by serial number, the date it left service, the method used, and the person who authorized it. Retain sanitization records that show the tool or procedure, its version, and the verification result. Where a third party collects or destroys media, keep chain-of-custody documents and any certificates of destruction that name the assets. Assign an owner for these records, review them on a set schedule, and retain them under the documentation rules in 45 CFR 164.316 so the trail still exists when a question arises years later.
How backups and recovery are evidenced
The sequence turns backup and restoration from an assumption into proof: the organization defines what ePHI is copied, keeps copies it can retrieve, tests restores, records the results and updates procedures when systems change. Each step leaves a record an assessor or OCR investigator can review. Retention periods and restore targets are set by the organization, so confirm them in your own environment before writing the procedures.
Define which ePHI is copied
Start by listing every system that holds ePHI on your infrastructure, such as the EHR database, file shares, imaging archives, interface engines and virtual machines that store patient data. Pair that list with your risk analysis and asset inventory so no ePHI store is left out. The security official or the system owner signs off on the list. The output is a backup scope register that names each system, its data owner and the copy method, which is the first document an assessor will ask for.
Create and store retrievable copies
Under 45 CFR 164.308(a)(7)(ii)(A), the organization must create and maintain retrievable exact copies of ePHI, a required specification. Configure backup jobs for each system in the register and send copies to storage that is separate from the production environment, including an offline or immutable copy where your risk analysis calls for one. Confirm the retention periods and copy frequency in your own environment, since these are business decisions. The output is job logs and a storage map showing where each copy lives.
Protect copies with the same safeguards
Backup media and storage carry ePHI, so the access controls, encryption and physical protections that apply to production also apply here. Restrict who can read, restore or delete backups, and log those actions. Where copies leave a secured facility, confirm the handling and transport steps are documented. Your device and media controls and the accountability specification for hardware movement cover this step. The output is an access list for backup systems and a record of who approved each change.
Write data restoration procedures
Under 45 CFR 164.308(a)(7)(ii)(B), the organization must establish and, as needed, implement procedures to restore any loss of data, a required specification. Write a runbook for each critical system that names the trigger for a restore, the people who authorize it, the order of recovery and the validation checks before users return. Set the recovery time and recovery point objectives in your own contingency plan, since the rule does not supply them. The output is an approved restoration procedure for each system.
Test restoration from the copies
Run restore tests from the stored copies, not from the live system, on a schedule your risk analysis supports. Restore into an isolated environment, check that records open, that data is complete and that integrity checks pass, and time the process against your stated objectives. A backup job that reports success does not prove a copy can be restored, so the test is the evidence that matters. The output is a test plan, the restored data checks and the elapsed times recorded for each system.
Record results and corrective actions
Document every restore test and real recovery event with the date, the system, the person who ran it, the outcome and any gaps found. Open a tracked corrective action for each failure, such as a missing dependency, an expired key or a copy that would not decrypt, and close it only after a retest passes. Keep these records with the rest of your security documentation so they remain available for the required retention period. The output is a restore test log and an action register with closure dates.
Update procedures after system changes
Every new system, migration, storage change or staff change can make a backup scope or runbook out of date. Tie the backup register and restoration procedures to your change management process so a change request cannot close without a review of backup coverage. Re-run a restore test on any system whose data path changed. The output is a dated revision history for the procedures and a change record showing the backup review was completed.
Who does what for an on-premises HIPAA program
The covered entity or business associate owns its Security Rule compliance. Under the Security Rule, the organization must designate a security official responsible for policies and procedures, and that accountability cannot be transferred to a vendor. In an on-premises program, your own staff run the facilities, the workstations, the media handling and the people who touch ePHI, so most day-to-day safeguards sit with them.
- Security official: Owns the written policies, approves risk management decisions and signs off on addressable specifications you decide not to implement, with a documented rationale.
- Facilities and operations staff: Control building access, visitor logs, server rooms, badge records and environmental controls for the facilities housing ePHI systems.
- IT and asset owners: Maintain workstation configuration, device inventories, disposal records and media re-use decisions.
- Workforce members: Follow access, workstation and device rules, and report lost devices or suspicious access.
- Management: Funds the work and reviews the risk analysis results.
Confirm with your counsel which internal roles and sign-offs your own policies require, since the Security Rule does not prescribe an org chart.
An implementation partner such as DeployOpen can plan, build, configure, harden and document self-hosted systems in your own facilities, and prepare the evidence your staff and assessors will review. The partner works under a written, fixed scope and does not own the controls. It does not issue reports, attestations or certificates, and it cannot tell you that you are compliant.
- Configuration and hardening: Sets up access control, audit logging, encryption settings and backup jobs on systems you run.
- Evidence preparation: Produces configuration baselines, screenshots, log samples, backup restore test records and disposal logs for your review.
- Documentation support: Drafts system descriptions and procedures for your security official to adopt, edit and approve.
- Handover and operating runbooks: Trains your staff so they can run the system after the engagement ends.
- Scope limits: Work is agreed in writing before it starts, and any physical facility changes that are outside the agreed scope remain your responsibility.
Ask any partner to state in writing what it will deliver, what it will not do, and that it will not issue compliance statements.
An independent assessor or auditor is engaged only when you want outside testing or a formal opinion. HHS does not endorse or recognize private certifications, and no Security Rule standard requires certification, so any third-party assessment is a report to your organization, not a government finding. Because assessors test the work they review, they must stay independent of the partner that built the system.
- Independence boundary: The assessor should not design or configure the controls it tests for the same organization.
- Testing: Samples evidence, observes facility controls and interviews staff against the Security Rule requirements.
- Output: Issues a written report of findings or opinion, which only the assessor can sign.
- Scope choice: Decide whether you want a readiness review, an internal audit or an external assessment, since each has a different purpose.
- Limits: A third-party assessment cannot replace OCR's authority to investigate or find a violation.
Before engaging anyone, ask what the assessor will report, who will sign it, and how it will treat conflicts with your implementation partner.
What on-premises HIPAA work costs and who gets paid
This table lists each cost component of running ePHI systems in your own facilities, who is paid for it, whether it is one-time or recurring, and what to ask for in a quote. No amounts are stated because none are supplied for this topic, so use the drivers column to scope your own estimate and the written scope to compare offers.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it, and what to ask for |
|---|---|---|---|
| Risk analysis and policy work for facility, workstation and media controls | Your internal staff time, with optional outside help from a consultant or implementation partner | One-time, then recurring when the analysis is updated | Number of facilities and ePHI locations. Ask the partner to name the deliverables, the review cycle and who signs off. |
| Facility access controls (badges, locks, visitor logs, camera coverage) | Your facilities team or a physical security vendor; hardware sellers | One-time installation, recurring maintenance and log review | Number of entry points and server rooms. Ask for the access logs and procedures the quote will produce. |
| Workstation and device controls (screen locks, cable locks, secured storage) | Your IT staff, plus hardware or software purchases where needed | One-time setup, recurring enforcement and audits | Number of workstations and mobile devices that access ePHI. Ask how enforcement will be evidenced. |
| Media disposal and re-use equipment and services (shredders, degaussers, certified destruction) | Equipment vendor or certified destruction provider, plus your staff for tracking | Equipment is one-time; destruction services and certificates are recurring | Volume and type of retired media. Ask for certificates of destruction and the NIST SP 800-88 method each vendor uses. |
| Backup infrastructure and off-site copies | Your IT team, hardware vendors, and any storage or DR provider you contract | Hardware one-time, storage and licenses recurring | Data volume, retention period and restore-test frequency. Ask for restore test results and the recovery procedure documentation. |
| Implementation partner fees for systems, configuration and evidence | The implementation partner, paid under a written, fixed scope | One-time for the project, optional recurring for support retainers | Scope of systems and facilities covered. Ask for a written list of deliverables, exclusions and acceptance criteria. |
| Independent assessment or audit of your controls | An independent assessor or auditor you engage directly | Typically recurring on your review cycle | Scope, number of sites and sampling depth. Confirm that the assessor issues the report, since HIPAA has no certification. |
| Ongoing staff time for access reviews, logs and training | Your internal staff; time is an internal cost, not an invoice | Recurring | Headcount, number of access changes and facility changes. Ask your partner which tasks you must keep in house. |
What makes on-premises HIPAA work cost more or take longer
On-premises HIPAA work is priced and scheduled mostly by how much physical and operational ground the Security Rule must cover. The cards below cover the drivers that expand that ground, and each one should be fixed in the written scope before any work starts so the quote and timeline can be compared on equal terms.
Number of facilities
Each facility that houses ePHI systems needs its own access controls, visitor logging, maintenance records and physical safeguard review under 45 CFR 164.310(a)(1). Multiple sites multiply site surveys, door and badge configuration, and evidence collection. Ask for the facility count, which sites host servers or workstations that touch ePHI, and whether remote or home workstations are in scope.
Workstations and devices
Section 164.310(c) requires physical safeguards for every workstation that accesses ePHI, so the device count sets how much inventory, configuration review and sampling evidence is needed. Shared clinical workstations, kiosks and mobile devices add per-device work. Confirm the total count, how devices are inventoried today, and whether a current asset list exists before work is quoted.
Media volume and disposal
Disposal and media re-use are required implementation specifications under 45 CFR 164.310(d)(1). The more drives, tapes, printers with storage and removable media you hold, the more tracking, sanitization and certificate-of-destruction records you must produce. Ask how many media items are in service, whether a chain of custody exists, and which sanitization method your records will reference.
Legacy hardware and unsupported systems
Older servers, workstations and embedded devices often cannot run current encryption, logging or patching, and each one needs a documented risk decision or a compensating measure. Under the addressable specifications, that reasoning must be written down and reviewed. Ask for the age and support status of each system, which ones cannot be upgraded, and whether they can be isolated on a separate network segment.
Backup and recovery complexity
Creating retrievable exact copies of ePHI and restoring after data loss are required under 45 CFR 164.308(a)(7)(ii)(A) and (B). Backup complexity grows with the number of systems, off-site copies, retention periods and restore tests. Your own facilities also mean you must provide the off-site location and its physical safeguards. Confirm which systems hold ePHI, where copies go, and how often restores are tested.
Maturity of existing policies
Written policies and procedures are required for every Security Rule requirement under 45 CFR 164.316. Organizations with no current policies, or with policies that describe practices nobody follows, need drafting, approval and staff training before evidence can be gathered. Ask for the current policy set, its last review date, and which procedures are documented but not practiced.
How the on-premises readiness process runs
The sequence moves from defining which ePHI systems and facilities are in scope to a documented set of physical, workstation and media safeguards that you can show to an assessor or customer. Each phase produces an artifact the next phase depends on.
Scope the ePHI systems and facilities
Your privacy and security leads, with IT and facilities staff, list every location and system where electronic protected health information is created, received, stored, processed or transmitted. That includes servers in closets, data center racks, clinical workstations, laptops, mobile devices, backup tapes and removable media, and printers or scanners that hold ePHI. The output is a written inventory of systems, rooms and devices with an owner for each. You know this step is done when every item in the inventory can be traced to a named owner and a physical location.
Complete the risk analysis OCR expects first
The security official leads a risk analysis that identifies threats and vulnerabilities to the inventoried ePHI, rates the likelihood and impact of each, and records what controls already exist. HHS offers a free risk analysis tool and publishes OCR guidance on the method, which you can use as a starting point. The output is a documented risk analysis and a prioritized list of risks, including facility access, unattended workstations, device loss and media disposal. This step is complete when the analysis is signed, dated and tied to the scoped inventory.
Document a risk management plan
Using the risk analysis, leadership decides which risks to reduce, accept or transfer, and assigns an owner and a target for each treatment. The plan should state how each Security Rule requirement applies to your facilities and systems, and which addressable specifications you have judged reasonable and appropriate. Where an addressable specification is not adopted, the decision and any equivalent alternative measure must be written down. You know this step is done when every high-priority risk has an approved treatment and an accountable owner.
Close gaps in physical and media controls
Facilities and IT staff implement the controls the plan requires: restricted and logged facility access, workstation placement and screen privacy, device inventory and tracking, documented media disposal and re-use procedures, and tested backup and restore steps. Disposal and re-use steps should follow the HHS guidance and the NIST SP 800-88 approach for sanitization, and records of each destruction or wipe should be kept. The output is configured controls and completed change records. This step is complete when each control has been applied in the environment, not only written down.
Test the controls and record the results
Someone other than the control owner checks each safeguard against the plan. Typical checks include sampling access logs for a facility door, verifying that a workstation locks after inactivity, confirming a sanitized drive cannot be read, and running a restore from a backup copy. Failed checks go back into the risk management plan with a new owner and a date. The output is a test log showing what was checked, when, by whom and what was found. You know this step is done when every control in scope has a passing or tracked result.
Assemble the evidence file
The security official gathers the policies, procedures, risk analysis, plan, configuration records, access and disposal logs, backup test results and training records into one controlled repository. Documentation should show who approved each item, when it was last reviewed and what changed. The output is an evidence index that maps each physical, workstation and media safeguard to the artifacts that support it. Confirm with your counsel or compliance team how long documentation must be retained and kept available, since that obligation sits in the Documentation standard.
Decide on an independent assessment
If a customer, regulator or board requires outside assurance, you choose an independent assessor and agree the scope in writing. Be clear with the assessor about roles: your organization owns the controls, an implementation partner can help prepare systems and evidence, and only the assessor issues any report or opinion. HIPAA has no certification, so ask the assessor exactly what the deliverable will say. The output is an engagement letter and an agreed scope. This step is complete when the scope matches the inventory from the first phase.
What must be in place before an assessment
An assessor will not accept a verbal explanation of your facilities, devices and recovery process. Each item below is a record you should be able to produce on request, and together they show how the physical and contingency safeguards work in practice.
Current ePHI system inventory
List every system that creates, receives, stores or transmits ePHI in your facilities, including servers, storage arrays, imaging systems, databases and any self-hosted application. Record the physical location, the owner and the data classes held. Check it against network scans and asset records, because a list built from memory usually misses a server in a closet or a backup appliance. Confirm the inventory is dated and reviewed when systems change.
Written physical safeguard policies
The facility access control standard requires policies and procedures that limit physical access to ePHI systems and the buildings holding them, while still allowing authorized access. Confirm you have a written policy for each physical safeguard: facility access, workstation use and security, and device and media controls. Each policy should name an owner, state who may enter server rooms, and describe how access is granted, reviewed and removed. Test whether staff can explain the policy without reading it.
Workstation and device inventory
Workstations that access ePHI need physical safeguards that restrict use to authorized users. Maintain a register of every workstation, laptop, mobile device and removable medium that touches ePHI, with the assigned user, location and physical controls such as locking, screen privacy and cable security. Reconcile the register against directory and endpoint management records every quarter. Gaps between the register and what is actually on the network are a common finding.
Disposal and re-use logs
Disposal and media re-use are both required implementation specifications, so each drive, tape, or device that held ePHI should leave a traceable record. Keep logs that show the item, its serial number, the method used (clear, purge or destroy), the date and the person who performed it. HHS treats media as secured when they are cleared, purged or destroyed consistent with NIST SP 800-88, so the log should name the method. Check that logs exist for hardware returned to vendors and leased equipment.
Tested backup restores
Creating retrievable exact copies of ePHI and establishing procedures to restore lost data are both required specifications. A backup job that reports success does not prove that data can be recovered. Keep records of restore tests that show the data set, the date, the time to restore and whether the restored data matched the source. Test at least the systems your contingency plan treats as most critical, and confirm that backup media are stored and protected under your physical safeguard policies.
Addressable specification decision record
For each addressable implementation specification, the entity must decide whether it is reasonable and appropriate. If it is not, the decision and the equivalent alternative measure must be documented. Keep one dated record per specification, covering accountability and data backup and storage in the physical safeguards, with the reasoning, the approver and the review date. An assessor will ask for this record first, because an unexplained omission is treated as a gap even when a sound control exists.
Questions buyers ask about on-premises HIPAA
Is there a HIPAA certification for on-premises systems?
No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private organizations' certifications, and that such certifications do not prevent HHS from later finding a violation. Your organization owns compliance and must be able to show its own documented safeguards, risk analysis and evidence. Any firm that offers a "HIPAA certificate" for your facility is selling an opinion or a checklist, not an official status. Ask what the document actually attests to, who issued it, and whether it would be accepted by OCR in an investigation.
How long does on-premises HIPAA readiness take?
No general duration is set by the Security Rule, so the timeline depends on the work in front of you. The main drivers are the size of the ePHI footprint, how many facilities and workstations are involved, how current your risk analysis is, whether policies and procedures already exist in writing, and how many physical controls need to be built or changed. Ask any provider for a written scope with named deliverables and a schedule tied to each one. Treat a timeline that is not linked to a defined scope as a warning sign.
Can our own team handle on-premises HIPAA work internally?
Often yes, for a team that has security, facilities and compliance skills and time to spare. The Security Rule is written in terms of outcomes, so internal staff can work from the HHS risk analysis guidance and NIST SP 800-66 Rev. 2, which is informational rather than binding. The risks are capacity and independence. Someone must own the risk analysis, the physical access policies, the media disposal records and the backup restore tests, and those duties need to continue after the project ends. Ask whether your team can keep the evidence current, not only create it once.
What does on-premises HIPAA need from our staff day to day?
The work is mostly operational. Staff need to follow facility access procedures, such as badge or key control and visitor logs, keep workstations physically restricted to authorized users, and follow media handling steps when hardware is reused or retired. The security official and facilities staff must review access lists and sign off on disposal. Records must be kept in a form you can show an assessor. Plan for training and periodic checks so that the procedures are followed in practice, not only written down.
How do we check that backups and media disposal actually work?
Test them and keep the records. The Security Rule requires retrievable exact copies of ePHI and procedures to restore any loss of data, both required. A backup that has never been restored is not evidence of recoverability, so schedule restore tests and log the results. For disposal, HHS guidance treats paper as secured when shredded or destroyed so PHI cannot be reconstructed, and treats electronic media as secured when cleared, purged or destroyed consistent with NIST SP 800-88, which HHS lists as informational. Redaction is specifically excluded. Keep a chain-of-custody and destruction certificate from whoever performs the work.
What can an implementation partner do for on-premises HIPAA, and what can't it do?
A partner such as DeployOpen can plan, implement, harden, back up, document and support self-hosted systems inside your own facilities and networks, and prepare the controls and evidence that a compliance review will examine. It cannot own your compliance obligations, sign off on your risk analysis as your decision, or issue an audit report or certificate. Only an independent assessor can issue an attestation, and HIPAA has no certifying body to issue a HIPAA certificate. Agree on a fixed written scope that lists which safeguards the partner prepares and which remain with your security official, and ask for the evidence package in writing.
How DeployOpen prepares on-premises HIPAA systems and evidence
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own facilities, data centers or networks. We prepare the systems, controls and evidence for your Security Rule assessment, while your organization owns its safeguards and the independent auditor or assessor issues any report.
How we scope
- Engagements are fixed-scope, with systems, facilities and deliverables agreed in writing before work starts.
- The written scope lists which ePHI systems, workstations, devices and media fall inside the work.
- Scope also names the physical safeguards you retain, such as facility access and media disposal.
How we build
- We configure self-hosted platforms in your facilities to support access controls, workstation restrictions and backup procedures.
- Testing covers recovery of backups to confirm retrievable exact copies can be restored when needed.
- Security testing for applications, infrastructure and APIs can be included where the written scope requires it.
How we hand over
- You receive documentation of configurations, procedures and the evidence each safeguard produces.
- Handover includes runbooks for media sanitization, disposal logs and restoration tests for your own staff.
- Your organization decides which controls to adopt, and an independent assessor determines compliance.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can keep platform patching, backup verification and evidence collection current between assessments.
- Ask for the support scope in writing so responsibilities for each safeguard stay clear.
