Guard authorized security testing policy
Target authorization, scope, rules of engagement, techniques, emergency stops, credentials, evidence, and deliverables for Guard assessments.
Last revised: October 23, 2026
This Authorized Security Testing Policy ("Policy") governs Guard automated authenticated and unauthenticated scanning, annual penetration-testing engagements, on-demand tests, and agreed security audits. It supplements the Terms and Acceptable Use Policy. Each assessment requires verifiable target authority and an approved written scope; the availability or purchase of a testing capability does not itself authorize activity against a reachable system.
Ownership and third-party permissions
Customer represents and warrants that it holds, and shall maintain for the assessment period, the permissions necessary to authorize each target and approved method. Customer shall identify each asset's legal owner or authorized operator, supply verifiable authorization, and disclose relevant shared hosting, carriers, managed providers, and third-party services. Solarius shall act within the authority actually granted and remains responsible for its own compliance with scope and reasonable-care obligations. Permission to administer an application does not necessarily authorize testing the underlying shared platform or its other tenants. Obtain provider approval when its rules require it.
Ownership verification establishes the target relationship, not unlimited authority for every technique. Scope must separately identify networks, hostnames, applications, interfaces, accounts, environments, and any excluded systems. An asset-group tag change cannot enlarge the agreed engagement. No addition of a target, technique, privilege level, testing window, or permitted impact shall take effect without a reviewed written revision and approval from the designated authority before the affected work proceeds. An instruction from a person lacking that authority shall not vary the engagement.
Rules of engagement before work starts
Open Assessments → Penetration tests → Request engagement to propose the scope. Before scheduling, review Engagement → Rules of engagement with the coordinator and service owner. The approved record must establish:
- Authorizing legal entity, technical owner, test coordinator, and named approval authority.
- Exact targets, environments, boundaries, permitted source addresses, and third-party approvals.
- Dates, hours, time zone, request-rate and concurrency limits, and excluded blackout windows.
- Permitted techniques, validation depth, privilege boundaries, and prohibited actions.
- Test accounts, credential handling, temporary access, and cleanup responsibilities.
- Sensitive-data boundaries, minimum proof needed, evidence access, retention, and export rules.
- Expected defender notification or approved blind-testing arrangement and how genuine attacks remain distinguishable.
- Emergency contacts, stop conditions, pause acknowledgement, restart approval, and recovery ownership.
- Effort, deliverables, urgent-finding route, retest scope, and any separately priced additional work.
Routine scanner schedules likewise need verified targets, approved windows, credential scope, rate limits, and an accountable owner. The availability of an authenticated scanning field is not permission to submit another person's credentials.
Methods requiring separate explicit approval
Denial-of-service or exhaustion tests, social engineering, physical access, phishing, malicious payload deployment, persistence, destructive actions, large-scale password attacks, and extraction of production datasets are excluded unless individually approved in the rules of engagement with containment and recovery controls. Even approved testing must stay within binding law, third-party permission, and safeguards for unrelated people and tenants.
Do not expand a proof of concept into mass extraction merely to demonstrate scale. Prefer a harmless marker, controlled test record, narrow result sample, or other bounded validation that shows the issue without unnecessary harm. A critical discovery does not authorize unilateral lateral movement into a new target. Escalate for a specific scope decision.
Credentials and monitoring
Provide dedicated least-privilege test accounts when possible, through the approved credential workflow rather than an ordinary email. Set expiry and revocation responsibilities. Record temporary firewall exceptions, monitoring suppressions, and allow rules with an owner and end time. Blind testing must not disable essential safety, evidence preservation, or the emergency contact path.
The customer must identify fragile systems and known operational constraints. Solarius applies agreed rate and safety controls and escalates unexpected effects. Approved production testing can affect performance; that foreseeable risk does not waive Solarius's duty to stay within scope and exercise reasonable care.
Stop, pause, and restart
Solarius and Customer shall cause assessment activity under their respective control to stop or pause upon an agreed emergency trigger, credible unauthorized impact, unexpected access to highly sensitive out-of-scope data, loss of required permission, or a valid instruction from the named authority. Further testing shall remain suspended until the approval required below has been recorded. At Engagement → Timeline, select Request pause and contact the emergency coordinator listed in the rules. A queued pause is not proof that active tools have stopped.
The coordinator must confirm acknowledged cessation, identify any already running action or side effect, preserve necessary evidence, and coordinate safe recovery. Revoking a scanner credential alone does not prove all accepted work ended. Restart requires the named authority's approval after scope, safety, and recovery concerns are resolved. Completed changes and collected evidence require their own authorized cleanup.
Findings, evidence, and incident handling
Communicate a critical finding through the approved urgent route rather than waiting for the final report. Restrict evidence to necessary facts, distinguish observations from hypotheses, and record target, time, method, and relevant identifiers. The DPA governs personal data. Evidence follows retention and deletion and the engagement schedule.
If testing reveals an unrelated active compromise, notify the authorized responder and agree incident-response scope; a test engagement does not automatically become an unrestricted response mandate. Do not share customer artifacts through the intelligence network. Preserve originals and integrity information, produce separately identified redacted exports, and limit report distribution to approved audiences.
Completion, annual coverage, and retesting
At Engagement → Deliverables, review tested and untested scope, methodology, limitations, findings and severity rationale, evidence, executive summary, and agreed remediation guidance. Revoke temporary accounts, remove approved exceptions, verify cleanup, and record any remaining customer action or retained evidence. A finding represents the observed condition and test period, not a guarantee that no other vulnerability exists.
The included annual engagement is the scope and effort identified in the accepted agreement. It does not imply unlimited applications, continuous penetration testing, or every future release being retested. Additional work and retests must identify scope, timing, deliverables, and any price before acceptance. An audit report can support compliance review without itself certifying the organization.
Testing Solarius-hosted products or infrastructure requires separate authorization under security disclosure. Authorization to assess your own environment does not transfer to Solarius or other customers.