A.6.7 Remote working: requirements and evidence

What ISO 27001 A.6.7 remote working requires in practice

A.6.7 Remote working asks the organization to put security measures in place for personnel who work remotely, so that information accessed, processed or stored outside the organization's premises stays protected. The control is a design obligation, not a product: the organization decides which remote work is allowed, on what devices and networks, with which data, and then shows an assessor that those decisions are applied and checked. Risk comes from home routers with default settings, shared family computers, unlocked screens in cafes and airports, personal cloud sync folders, and printed or downloaded files left in unmanaged places. The control's name is a little narrower than its reach: it governs the work arrangement as well as the technology behind it.

The control has a clear lineage. The correspondence table in ISO/IEC 27002:2022 Annex B traces A.6.7 to A.6.2.2 Teleworking in the 2013 edition, so organizations that certified under the earlier standard already had a teleworking control to map forward. The 2022 wording is broader in practice because it covers any remote location, not only a designated home office, and it sits next to A.8.1 User endpoint devices, A.7.9 Security of assets off-premises and A.8.5 Secure authentication. The reader should check the Statement of Applicability to confirm which of these related controls carry the remote-work evidence, so the same screenshot is not counted twice or missed entirely.

It is hard because remote work crosses five domains at once: policy (who may work remotely and with what data), devices (managed or personal, encryption and patching), identity (strong authentication and session control), network (how traffic leaves an unmanaged location) and people (training, reporting lost equipment and handling physical exposure). A gap in any one of them weakens the others. Before scoping, confirm with the business which roles work remotely, which systems they reach, and whether any work happens in public places, then decide which evidence each domain will produce. This is the planning step where outside help is most useful, because the decisions belong to the organization while the configuration and evidence work can be prepared by an implementation partner.

Which remote work arrangements fall inside the A.6.7 scope

Remote work is not one arrangement. Who the worker is, where they sit, what device they use and how they reach company systems each change what A.6.7 Remote working must cover. Decide these questions first, then write the scope statement and Statement of Applicability entries from the answers.

Employees versus contractors

A.6.7 applies to anyone who accesses, processes or stores information outside your premises, not only to staff on payroll. Contractors, temporary staff and outsourced operators often hold the same access. Check whether their remote work is governed by the same policy, the same device rules and the same access reviews. Record the contractor population in the scope and confirm their agreements reference the remote working requirements.

Home offices versus public places

A home office carries household risks such as shared networks, family members and unsecured printers. Public places add shoulder surfing, theft, public Wi-Fi and unknown neighbors. Many organizations allow home work but ban cafes or co-working spaces, or require privacy screens and a rule against open discussion of sensitive data. Decide which locations are permitted and document how the rule is communicated and checked.

Company-managed versus personal devices

A company-managed laptop can be configured, patched, encrypted and wiped remotely. A personal device used for email or file sync usually cannot, and it may hold data the organization cannot retrieve or delete. Decide which devices may access which systems, and state what happens to company data on a personal device after an employee leaves. Link this decision to A.8.1 User endpoint devices, which sets the endpoint requirements that remote devices must meet.

VPN or zero-trust access versus browser-only access

A VPN places a remote device on a network segment, so its reach and logging must be scoped and reviewed. Zero-trust and browser-only access grant per-application sessions, which limits what a compromised device can reach. Each model produces different evidence: VPN logs and firewall rules for one, identity and session records for the other. Document which model applies to which system, and check that access is controlled and logged under either approach.

Remote staff in other countries

Working from another country can bring local labor, tax and data protection rules, export controls on certain technologies, and government access risks. A remote worker abroad may also connect through networks you cannot inspect. Confirm with legal counsel which countries are permitted, how access is restricted by location, and whether the country affects the information that person may handle. Record these rules in the remote working policy.

Cloud systems accessed from anywhere

A SaaS application or cloud workload reachable from any network is often the main remote access path, even when no one thinks of it as remote working. These systems need scoping alongside A.8.1 and A.7.9 Security of assets off-premises, because the data leaves your premises whenever a user opens it. Confirm which cloud services are in scope, how their access is restricted and whether their logs are retained for review.

How an assessor tests remote working controls

This table sets out, for each area of remote working, what an assessor typically tests, the evidence they ask for and where organizations most often fall short. Read it as a checklist of what to have ready before an audit, not as a list of requirements quoted from the standard. NIST's crosswalk relates A.6.7 to AC-17 and PE-17, but NIST cautions that mapped controls are not always equivalent, so confirm each mapping against your own scope.

Area	What the assessor tests	Evidence requested	Common findings
Remote working policy	Whether a documented policy defines which roles may work remotely, from where, and under which conditions	Approved policy version, approval record, review dates, staff acknowledgments	Policy exists but does not name locations, data types or approval roles
Device requirements	Whether remote devices meet the same baseline as office devices, including encryption, patching and endpoint protection	Device inventory, configuration baseline, compliance reports from management tooling	Personal devices used for company data with no enrollment or baseline check
Connection and authentication	Whether remote sessions use encrypted tunnels, managed access paths and strong authentication	VPN or zero trust access configuration, firewall rule exports, MFA enrollment and enforcement records	Remote access open to the internet without MFA, or shared accounts used for access
Physical security at home or in public	Whether staff protect screens, paper records and devices outside the office, and whether the organization gives clear guidance	Written guidance on workspace and travel, acknowledgment records, incident records for lost or stolen devices	Guidance absent, or staff unaware that working in public spaces is restricted
Records showing enforcement	Whether controls operate in practice, not only on paper, and whether exceptions are approved and reviewed	Access logs, firewall rule match logs, exception register, periodic review minutes, sample of remote user records	Logs not retained or not reviewed, and no record of exceptions granted
Coverage of remote staff and contractors	Whether the population of remote workers is known and all of them fall under the controls	Remote worker list cross-checked with identity directory, contractor agreements referencing remote terms	Remote contractors or temporary staff missing from the population
Related controls	Whether remote working links to endpoint, off-premises asset and authentication controls	Cross-references in the Statement of Applicability to A.8.1, A.7.9 and A.8.5	Remote working treated as a standalone topic with no link to asset or access controls

How to implement remote working controls step by step

This sequence turns A.6.7 into a working control: a policy that defines who may work remotely, an inventory of what leaves the premises, technical safeguards, staff acknowledgment and ongoing review, each producing evidence an auditor can sample.

Define the remote working policy and its scope
Start by writing a remote working policy that states who it covers (employees, contractors, temporary staff and third parties), which locations count as remote (home, hotels, co-working spaces, travel) and which roles or activities are excluded. Assign an owner, usually the CISO or head of IT, and have management approve it. Done means an approved, dated policy version that sits in the management system document set and is linked from the Statement of Applicability entry for A.6.7. Ask the organization to confirm which teams already work remotely so the policy describes reality rather than an idealized model.
Classify information that may leave the premises
Work with information owners to identify which information assets may be accessed, processed or stored away from the office, and which must stay on-premises or in controlled systems only. Use the existing asset inventory and information classification scheme, and record the result as a register that maps each classification level to permitted remote handling. Done means a signed-off register that the access and device rules in later steps can reference. This step also feeds the asset controls for off-premises assets, so keep the two aligned.
Set device and connection requirements
Define the minimum requirements for devices used remotely: managed or approved endpoints, disk encryption, current operating system patching, endpoint protection, screen locking and restrictions on personal devices for classified information. Define connection requirements such as use of the organization's VPN or zero-trust access gateway, no access over untrusted public networks without it, and rules for shared or public Wi-Fi. Done means a published device standard and an asset-to-user register that records each device, its owner and its compliance status. Confirm the exact requirements with the organization's security and IT teams for its environment.
Implement identity and network controls
Configure remote access so that every session is authenticated, authorized and limited to the resources the role needs. Typical measures include multi-factor authentication for remote logins, role-based access groups, session timeouts and firewall rules that restrict remote access to specific services. Open-source options such as authentik can enforce second factors at login, FreeIPA can manage OTP tokens for directory users, and OPNsense can scope traffic with aliases and logged rule matches. Confirm each product's capabilities against your architecture before you rely on them. Done means tested configurations and access logs that show who connected, when, from where and to what resource.
Define physical security expectations for home and public settings
Write practical expectations for working outside the office: keeping screens out of view of others, locking devices when unattended, not leaving equipment in vehicles, storing paper records securely and discussing sensitive matters only in private. Address public places specifically, including use of privacy screens and avoiding overheard calls. Make clear what the organization provides and what staff must arrange at home. Done means these expectations are part of the policy and the staff briefing, with a note on how incidents such as lost devices are reported.
Train staff and collect acknowledgments
Brief everyone in scope on the policy, device standard, connection rules and physical expectations, then record their acknowledgment. Role-based content helps managers and staff who handle sensitive information understand the stricter rules. Explain how to report a lost device or suspected misuse, linking to the event reporting channel. Done means a completion record and a signed or electronically recorded acknowledgment for each person, kept with HR or training records so an auditor can sample them against the list of remote workers.
Build review and monitoring
Set up routine checks that the controls still work: review remote access logs, confirm device compliance against the asset-to-user register, review who holds remote access rights when roles change, and test that access is removed on leaving. Record the findings, decide corrective actions and feed exceptions into the management review and internal audit cycle. Done means dated review records, documented exceptions with approvals and evidence that corrective actions were tracked to closure. Ask the organization to confirm how often its reviews run, since the review frequency is set by its own risk assessment rather than by the standard.

How strong authentication and network controls support remote work

Second factors limit the damage from stolen remote access credentials, and for A.6.7 Remote working they are often the control an assessor will ask to see first. When staff connect from home or a coffee shop, a password alone is exposed to phishing, reuse and password spraying. A second factor checked at login means a stolen password does not by itself open the remote path. In authentik, the authenticator validation stage is the login step that checks enrolled second factors, including TOTP apps, WebAuthn and FIDO2 passkeys, and recovery codes. In FreeIPA, two-factor authentication covers HOTP and TOTP tokens, including software tokens enrolled by QR code and hardware tokens. Confirm in your own environment which factors are permitted for remote users, whether static recovery codes or SMS fallbacks are enabled, and which login flows bypass the stage.

Network logs show which remote paths were allowed, and web application filtering protects what remote users reach. OPNsense rules pass, block or reject traffic by source, destination, port and protocol, and each rule can log its matches for review in the live log view. Keep rules for remote access narrow, use aliases for the groups of staff and systems involved, and export or retain the log entries you will need for sampling. For web applications opened to remote staff, Coraza, a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, can block common attacks such as SQL injection and cross-site scripting. It integrates with Caddy, HAProxy, Traefik and Nginx, so confirm which of these sits in front of your applications and whether its rule set is tuned for them.

None of these tools proves the control. Each one must be checked against your own architecture, including where the identity provider, firewall and reverse proxy sit, whether remote traffic can reach internal systems without passing them, and who owns the configuration. A tool that supports second factors or logs rule matches still needs a documented policy, a defined list of approved remote paths and records that show the settings were in force during the audit period. An independent auditor will test the configuration and the logs, and DeployOpen can prepare those systems and evidence, but the organization owns the decision about what remote access is permitted.

Evidence that proves remote working is controlled

An assessor testing A.6.7 Remote working will ask whether the rules exist, whether people accepted them, and whether the technical controls behind them still work. The six artifacts below answer those questions in turn, and each one goes stale unless it is refreshed on a schedule between audits.

Approved remote working policy

The policy states who may work remotely, which locations and networks are allowed, what must never be stored on personal equipment, and who approves exceptions. Keep the approved version, its owner, its approval date and a full version history, so the auditor can see which rules applied on any given date. Between audits, set a review date in the document control register and record each review, even when nothing changes. Ask whether the policy is cross-referenced to the device, access and asset controls it depends on, since an assessor will check that the references hold.

Signed staff acknowledgments

Each person who works remotely should have an acknowledgment of the current policy version, dated and linked to their identity in the HR or identity system. Remote workers who joined before a policy change need a fresh acknowledgment, so track version against signer rather than checking only that a form exists. Ask for a report that lists anyone with remote access who has not acknowledged the current version, and schedule it to run before each audit window.

Device inventory and compliance status

Remote work relies on the endpoint, so the inventory must list every laptop, phone and managed device used off-premises, with its owner, operating system patch level, disk encryption status, and whether it passed the last compliance check. Export the inventory on a fixed cadence and keep the exports, because a single snapshot shows nothing about drift. Personal devices used for work need their own entries, or a documented decision that they are prohibited. This record is the evidence base for A.8.1 User endpoint devices as well.

Firewall rule records and logs

Firewall and access gateway rules that govern remote connections should be kept under change control, with each rule's purpose, owner and approval. For OPNsense, export the rule set and keep logging enabled on rules that admit remote traffic, so a reviewer can trace accepted and blocked sessions. Retain the logs for a period your policy sets, and sample them to confirm rules match what was approved. Confirm the retention period and log storage with your own legal and operational requirements.

MFA enrollment reports

Remote access must require a strong second factor, so the enrollment report should show, for each remote user, which authenticators are registered and when they were enrolled. In authentik, the authenticator validation stage determines which second factors a login accepts, so export both the stage configuration and the enrollment list. Flag accounts with only recovery codes or no factor at all, and review how lost-device recovery is approved. The same report supports A.8.5 Secure authentication.

Remote access reviews and exceptions

Access reviews show that remote access is still needed and still correctly granted. Record each review with its date, reviewer, population reviewed, decisions taken and removals completed. Exceptions, such as a temporary contractor connection or a home network that cannot meet the device standard, need a written approval, an expiry date and a closure record. Schedule reviews at a frequency your risk assessment supports and keep the completed review files, because an assessor will sample both the reviews and the exceptions that were closed.

What meeting A.6.7 costs in money and effort

This table breaks down the money and labor behind remote working controls, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Read it as a checklist for requesting quotes, since no price is stated here and open-source tools remove license spend but not staff time.

Cost component	Who is paid and for what	One-time or recurring	What drives it
Remote working policy drafting and legal review	Internal policy owner, legal counsel, HR, and any advisor preparing the document	One-time, with periodic review	Number of jurisdictions where staff live, and whether works councils or employment rules apply
Device management and endpoint licenses	Commercial MDM vendor, or staff time to run a self-hosted equivalent	Licenses recur; self-hosted tooling removes license spend but keeps labor	Device mix, number of remote devices, and whether personal devices are allowed
Identity and MFA tooling	Identity platform licenses or self-hosted service (for example authentik or FreeIPA), plus setup labor	Setup is one-time; hosting and support recur	Number of users, enrollment method for second factors, and migration from existing OTP systems
Network access and VPN engineering	Network engineers for firewall rules, remote access design and firewall logging (for example OPNsense)	Design and build one-time; rule changes and log review recur	Number of access paths, sites, and whether remote access reaches internal applications
Engineering and integration time	Internal platform team or implementation partner preparing systems and documenting configuration	One-time, with ongoing changes	Degree of customization, number of systems in scope, and existing infrastructure maturity
Staff training on remote work rules	Trainers, HR or security staff, and the time staff spend completing sessions	Initial rollout one-time; refresher training recurs	Workforce size, role-based content needs, and turnover
Evidence upkeep	Control owners collecting logs, device inventories, access reviews and exception records	Recurring	Frequency of access reviews, number of devices, and how much evidence is automated
External penetration testing of remote access	Independent testers, paid per written scope	Recurring, usually on a set cycle or after major change	Number of remote entry points, depth of testing, and retest scope
Auditor sampling and certification fees	Certification body, paid per its own quote; the organization owns the controls	Recurring across the certification cycle	Number of sites, sampling depth, and how well evidence is organized before the audit

Who owns remote working controls, and what partners can prepare

The organization owns A.6.7 Remote working in full. It decides who may work remotely, from which locations and on which devices, and it accepts the residual risk when a role cannot be fully controlled outside the office. No partner can make those decisions on its behalf, and an auditor will ask for the approvals that show management made them.

Policy ownership: Approve a remote working policy that names eligible roles, permitted locations, and the rules for public spaces and shared networks.
Risk acceptance: Record who accepted the risks of remote access for each exception, with a date and a review point.
Staff obligations: Make sure personnel acknowledge the rules, including locking screens, keeping devices with them, and reporting lost equipment.
Management approval: Keep signed approvals for the policy and for changes to it, so the record shows the decision came from accountable leadership.
Operation: Assign owners who review remote access logs and exceptions on a set schedule.

Before engaging anyone, confirm that a named executive owns the remote working decisions and that the policy text matches what staff actually do.

Common gaps that fail remote working audits

Assessors who test A.6.7 Remote working tend to find the same few weaknesses: the rules were never written down, the devices and connections were never controlled, and the access given to remote staff was never taken back. Each card below names one gap, why it matters for the control, and the check that closes it before the auditor arrives.

No written remote working policy

A.6.7 asks for security measures for information accessed, processed or stored outside company premises, and an auditor first looks for a document that sets those measures out. Without a policy, staff work from habit, and the organization cannot show what it required or who agreed to it. Check that the policy names approved locations, devices, connection methods, and what staff must never do in public, then confirm each person in scope has acknowledged it. Illustrative: a policy that covers only VPN use will miss home printing and screen viewing on trains.

Unmanaged personal devices

Laptops and phones that staff own, or that no one configured, reach company systems without the baseline that A.8.1 User endpoint devices expects. Remote work multiplies this risk because the device may never return to the office for patching or inspection. Confirm which devices may access company data, require encryption, screen lock, current operating system patches and endpoint protection before enrollment, and keep a current device inventory an auditor can sample.

MFA not enforced on every remote path

Organizations often protect the main VPN or single sign-on page with multi-factor authentication, then leave a legacy web mail, file share or administrative console open with a password alone. An assessor who tests remote access will try those paths. List every route into company systems from outside the office, including vendor and administrator access, and confirm each one requires a second factor. The control to look at alongside this is A.8.5 Secure authentication.

Remote access logs not kept or reviewed

An auditor needs to see that remote sessions were recorded and that someone looked at the records. Gaps appear when VPN, firewall and identity logs roll over after a few days, or when they sit on the device that generated them with no review. Confirm which sources record remote logins, where they are stored, how long they are kept under the organization's retention rule, and who reviews unusual sign-ins and how that review is recorded. OPNsense can log each rule match for review in its live log view, which helps establish that the firewall side is recorded.

No guidance for public places

Work in cafés, airports and shared workspaces exposes screens and conversations to people who should never see them, and this exposure is part of the physical side of A.6.7. Many organizations never tell staff what to do there. Issue short written guidance on privacy screens, not leaving devices unattended, avoiding confidential calls in open spaces and using only approved connections, then record that staff received it. Confirm the guidance is consistent with the controls in the physical theme where the device is lost or stolen.

Remote access survives offboarding

A leaver's VPN profile, remote desktop account or token often stays active after the HR record closes, because remote access is provisioned in a different system from the directory. This is a frequent audit finding because it links directly to the termination and role-change duties in A.6.5. Build offboarding steps that revoke VPN certificates, remote sessions, tokens and vendor accounts at the same time as the directory account. Then test it: pick a recent leaver and show that each remote path refused them.

Questions buyers ask about A.6.7 remote working

How much effort does A.6.7 remote working take to meet?

The effort depends on how many people work remotely, which information they reach from outside the office, and how much of that access already runs through managed devices and controlled connections. A.6.7 asks for security measures for personnel working outside the organization's premises, so the work is mostly policy, device and connection requirements, plus records that show those measures operate. Organizations with a small, mostly managed fleet usually spend less time than those with many unmanaged personal devices or broad access to internal systems. Ask any provider to break its estimate into policy work, technical configuration, evidence collection and staff communication, and to state which of those depend on your current tooling.

Can a small team handle A.6.7 remote working on its own?

A small team can often handle A.6.7 internally if one person owns the remote working policy, someone can configure and check the devices and connections staff use, and the team can produce evidence on a routine basis. The harder parts are usually keeping the policy aligned with how people actually work and running reviews consistently across the ISMS cycle. Small teams should also confirm that the same people are not both operating the controls and judging whether they work, since an auditor will look for that separation. A short internal gap check against the control's purpose is a practical first step before deciding what to hand off.

What part of A.6.7 should an organization outsource?

The organization keeps ownership of its controls, so what gets outsourced is preparation work, not the decision that the controls are effective. Common candidates include configuring VPN or zero trust access, setting up device management baselines, building evidence collection, and drafting the remote working procedure for internal review. Management decisions, risk acceptance, policy approval and staff accountability should stay in-house. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and prepares systems and evidence for assessment, but it does not issue audit reports or certificates. Any scope should be agreed in writing before work starts.

How long does preparing for A.6.7 usually take?

Preparation time depends on scope, and no fixed duration applies to every organization. The main drivers are the number of remote roles, how many devices and connection paths need to be brought under policy, whether remote access is already logged and reviewed, and how much existing documentation can be reused. Organizations already running managed endpoints and identity controls generally have less to build than those starting from unmanaged laptops and shared credentials. Ask for a timeline tied to a written scope with named deliverables, and confirm which dependencies, such as staff training or hardware procurement, sit outside the provider's control.

Do self-hosted open-source tools remove the licensing cost of A.6.7?

Self-hosted open-source tools can reduce recurring software license fees, but they do not remove cost. Open-source licenses such as those used by OPNsense (BSD-2-Clause), authentik (MIT) and FreeIPA (GPL-3.0-or-later) permit use without a license fee, yet the organization still pays for hosting, staff time, configuration, upgrades, backups and support. Those costs are one-time for initial setup and recurring for operations. When comparing options, ask a vendor to separate license fees from infrastructure, labor and support, and check each component's license terms against your intended use, because licenses differ.

Can a consultant or implementation partner certify us to ISO 27001?

No. A consultant or implementation partner cannot certify an organization to ISO 27001. ISO does not certify organizations, and only accredited certification bodies can issue an ISO/IEC 27001 certificate after an independent audit. Implementation partners prepare systems, configurations and evidence for A.6.7 and the rest of the ISMS, but the certification decision belongs to the certification body. To check a certificate, use the IAF CertSearch database that ISO points to, and confirm the certification body's accreditation status. Keep the partner and the auditor independent so that the audit tests the organization's controls rather than work the auditor helped design.

How DeployOpen approaches remote working controls

DeployOpen plans and implements self-hosted platforms inside your own infrastructure, and for remote working that means the access paths your personnel use from home, hotels and client sites. Our work covers hardening the remote access layer, producing the configuration and records that show it is controlled, and testing the access paths for weaknesses. The organization owns the control. Your leadership decides the remote working policy, which roles may work remotely, which devices are permitted and what happens when someone breaks the rules. DeployOpen does not issue audit reports, attestations or certificates. An independent certification body or auditor decides whether A.6.7 is met.

In practice, we typically work through the components an auditor will ask about: the VPN or zero trust access gateway, the firewall rules that limit what a remote session can reach (for example, rules on OPNsense with aliases for remote user groups and logging enabled for each rule match), the second factor checks enforced at login (for example, authenticator validation in authentik or OTP enrollment in FreeIPA), and the web application firewall in front of internal portals that remote staff use (for example, Coraza with the OWASP Core Rule Set). Each of these produces configuration files, logs or enrollment records that you can present as evidence. Your team should confirm that each platform capability it relies on is supported in the versions it runs before the design is fixed.

Before you commission this work, decide three things with your compliance lead: which remote access paths are in scope, which evidence your auditor will sample (access reviews, device records, login logs and testing reports are common examples), and who signs off the remote working policy. Ask any implementation partner to write these decisions into the statement of work, including what is delivered, who keeps the evidence after handover and how changes to the access design are approved. Finally, ask for a security test of the remote access path before the audit, since a failed test found in advance is far cheaper to fix than a nonconformity raised during certification.

How DeployOpen scopes and evidences A.6.7

DeployOpen approaches A.6.7 Remote working as a scoped piece of work inside the client's own infrastructure. We prepare the remote access, endpoint and logging controls that show remote work is governed, while the organization keeps ownership of its policy, its controls and its risk decisions.

How we scope

Agree in writing which remote access paths, staff groups and systems the A.6.7 work covers.
Confirm with your team which home, public-place and travel working situations the remote working rule must address.
List the Annex A controls that touch remote work, such as A.8.1, A.7.9 and A.8.5, so the boundary is clear.

How we build

Configure remote access controls, such as VPN or gateway rules, in your own cloud accounts or data centers.
Set up second-factor authentication for remote logins using self-hosted tools such as authentik or FreeIPA, where they fit your environment.
Enable logging of remote access and rule matches so that reviewers can later see who connected and when.

How we hand over

Document each configured remote working control with its owner, configuration location and review frequency.
Deliver the evidence set your auditor will sample, such as configuration exports, access logs and authentication records.
Walk your security and IT staff through the runbook so they can operate and review the controls after handover.

How we support

Offer ongoing support, upgrades and continuous testing of remote access systems as a retainer, if you need it.
Retest remote access paths after changes, so new configurations do not quietly weaken the controls.
Note that DeployOpen prepares evidence, while independent auditors and certification bodies alone issue reports or certificates.