Acceptable use and written authorisation

Document id: authorisation Draft version: auth.draft-0 Form reference: AUTH-________ (assigned by Reconesys when the form is issued)

Read this first

Nothing in this form is needed for a free exposure snapshot. A free snapshot reads public records only and never connects to your systems. If that is all you are doing, you do not need this document.

This form exists for the step after that: checks that connect to systems you control. Under Kenya’s Computer Misuse and Cybercrimes Act 2018 (as amended in 2025), connecting to somebody’s system without authority is an offence, and Kenya has no responsible-disclosure safe harbour. Written authority from somebody who can actually give it is what separates lawful work from an offence. That is what this document is, and it is why it asks for specifics rather than a general blessing.

This is not a penetration test. The techniques permitted by this form are listed exhaustively in Part D and they stop well short of one: we connect and observe, we do not exploit. If you want a penetration test, engage a firm that does them, under a separate and much more detailed agreement.

[COUNSEL: confirm the Cybercrimes Act framing, and advise whether an authorisation of this kind is best drafted as a standalone deed, as a schedule to the services agreement, or as both. Advise also whether any offence under that Act is one that consent cannot cure, which would set a ceiling on what this form can lawfully permit however carefully it is drafted.]

Part A — The parties

Service provider

Field	Value
Legal entity	{{LEGAL_ENTITY}}, trading as Reconesys
Address	{{POSTAL_ADDRESS}}
Email	{{CONTACT_EMAIL}}
Telephone	{{PHONE}}
ODPC registration	{{ODPC_NUMBER}}

Customer

Field	Value
Legal entity (full registered name)	________________________________________
Company / business registration number	________________________________________
Registered address	________________________________________
Operating address, if different	________________________________________
Primary technical contact — name	________________________________________
Primary technical contact — role	________________________________________
Primary technical contact — email	________________________________________
Primary technical contact — mobile (reachable during the window)	________________________________________

Part B — What is being authorised, and why

Field	Value
Engagement / order reference	________________________________________
Service being delivered	________________________________________
Purpose of the active checks	________________________________________

The Customer authorises Reconesys to perform the techniques listed in Part D, against the assets listed in Part C, during the window in Part E, and for no other purpose.

Anything not expressly permitted by this form is not authorised. If Reconesys wants to do something outside it, we ask you first and you sign a variation under Part K. Silence is not consent and an oral agreement is not a variation.

Part C — Scope: exactly which assets

Complete every table. Leave a row blank rather than writing “all”, “any” or “et cetera” — an authorisation that cannot be read precisely is one that protects neither of us.

C.1 Domains and DNS zones in scope

#	Domain or zone	Subdomains included?	Notes
1	________________________	Yes / No	________________________
2	________________________	Yes / No	________________________
3	________________________	Yes / No	________________________

C.2 Hosts and IP addresses in scope

#	Hostname	IP address or range	What it is	Owned by the Customer, or hosted?
1	______________	______________	______________	______________
2	______________	______________	______________	______________
3	______________	______________	______________	______________

C.3 Web applications and endpoints in scope

#	URL	Environment (production / staging)	Notes
1	______________________	______________	______________
2	______________________	______________	______________

C.4 Explicitly EXCLUDED — do not touch

List anything inside the ranges above that must not be touched, and anything a reasonable person might assume is included but is not.

#	Excluded asset	Why
1	______________________	______________________
2	______________________	______________________
3	______________________	______________________

Excluded by default, in every engagement, unless a specific line is added above and initialled by both parties:

Clinical, diagnostic and patient-care systems, and any medical device or system connected to one.
Industrial control systems, SCADA, PLCs, building management and life-safety systems.
Payment systems, card data environments, and mobile-money integrations.
Anything belonging to a third party — a booking platform, a payment provider, a shared hosting neighbour, a supplier’s system — even where it carries your name.
Staff personal devices, personal accounts, and home networks.
Physical premises and physical access controls.
Employees and contractors as human targets. No social engineering, no phishing simulation, no pretext calls are authorised by this form.

C.5 Third-party infrastructure

Most Kenyan businesses run on somebody else’s infrastructure. Your authority does not extend to their systems, and ours cannot come from you.

Question	Answer
Are any in-scope assets hosted by a third party (hosting provider, cloud provider, SaaS platform, managed service provider)?	Yes / No
If yes, which assets and which provider?	________________________________________
Has that provider been notified, and does its acceptable-use policy permit this activity?	Yes / No / Not required
Evidence of the provider’s permission, where required (reference, ticket, or attached email)	________________________________________

Reconesys will not begin against a third-party-hosted asset until this row is complete. Several major providers require advance notice or explicit permission for exactly this kind of activity, and proceeding without it exposes both of us.

[COUNSEL: advise how much diligence we must do on the Customer's answer here. Our current position is that we take the Customer's written statement at face value but refuse to proceed where the answer is blank. Please confirm that is enough to protect us, or tell us what more to require.]

Part D — Permitted techniques, exhaustively

D.1 Permitted

Tick each technique that is authorised. An unticked technique is not authorised.

Tick	Technique	What it means in practice
[ ]	Passive public-record collection	Everything in the free snapshot: DNS, mail posture from DNS, certificate transparency, the public registry. Always permitted; listed here for completeness.
[ ]	TLS connection and observation	Opening a TLS connection to a named host and port and recording the certificate, protocol versions and cipher suites offered. No traffic beyond the handshake.
[ ]	HTTP and HTTPS requests to named hosts	Ordinary `GET` and `HEAD` requests to named hosts and paths, recording status codes, response headers and page content as returned.
[ ]	Reading published files	`robots.txt`, `security.txt`, `sitemap.xml`, and similar files a server publishes for anybody to read.
[ ]	Subdomain enumeration by DNS query against the zones in C.1	Querying names against your name servers to find hosts that resolve. Rate-limited per Part F.
[ ]	Service and version identification on named ports	Connecting to a named port on a named host and recording what the service announces about itself.
[ ]	Screen capture of in-scope web pages as they render	For the report.
[ ]	Other, described precisely: ________________________________________	________________________________________

D.2 Prohibited, in every case

The following are never authorised by this form, whatever is ticked above, and Reconesys will not perform them:

Exploitation of any weakness. We report what we observe; we do not prove it by exploiting it.
Injection or fuzzing of any kind, including SQL injection, command injection, template injection or file-upload testing.
Authentication attacks: password guessing, credential stuffing, brute force, password spraying, session hijacking, or testing credentials found anywhere.
Denial of service, stress testing, or load testing, deliberate or reckless.
Modifying, deleting or encrypting any data, or changing any configuration on your systems.
Extracting personal data, patient data, guest data, cardholder data or business records from any system. If a check reveals that such data is exposed, we record the fact and the location, take the minimum evidence needed to prove it, and stop.
Social engineering of your staff, contractors, guests or patients, including phishing simulations and pretext telephone calls.
Physical intrusion, tailgating, or any activity on your premises.
Wireless attacks, including attacks on your guest Wi-Fi.
Installing anything — software, agent, implant, or persistence of any kind — on any system.
Touching anything not listed in Part C, or anything listed in C.4.

[COUNSEL: confirm this prohibited list is complete for Kenyan law, and advise specifically on whether "service and version identification on named ports" in D.1 sits safely inside consent given by this form, or whether it needs its own heavier wording. It is the technique closest to the line.]

Part E — When

Field	Value
Authorised window — start (date and time, EAT)	________________________________________
Authorised window — end (date and time, EAT)	________________________________________
Permitted hours within that window	[ ] Any time [ ] Business hours only [ ] Outside business hours only [ ] Other: ____________
Blackout periods (month-end, a clinic day, a conference, a peak season)	________________________________________

Outside this window, nothing is authorised. If the work overruns, we stop and ask for an extension in writing under Part K. An expired authorisation is the same as no authorisation.

[COUNSEL: set a maximum window length. We propose that no single authorisation may run longer than 90 days, so that authority is refreshed by a live human decision rather than inherited from a form somebody signed a year ago and forgot.]

Part F — How we will behave while we are connected

Commitment	Value
Maximum request rate against any single host	________ requests per second `[COUNSEL: we propose a default of 5, stated in the form so it is a contractual limit rather than an intention]`
Source addresses our traffic will originate from	________________________________________ (supplied by Reconesys before the window opens, so your team can identify and, if needed, block it)
Identifying string our tools will send	`Reconesys-Assessment/AUTH-________ (contact: {{CONTACT_EMAIL}})`
We will pause immediately if	We observe instability, degraded response, or any sign that a system is struggling — whether or not you have asked us to stop

Sending an identifying string and a fixed source range is deliberate: your security team should be able to look at their logs, see immediately that the traffic is ours and authorised, and reach a human at the address in the string. Unattributable traffic during an authorised engagement wastes your team’s night and ours.

Part G — Emergency stop

Either party can stop the work at any moment, for any reason or none, with no notice and no penalty.

Role	Name	Email	Mobile (24 h during the window)
Customer’s emergency-stop contact	______________	______________	______________
Customer’s alternate	______________	______________	______________
Reconesys engagement lead	______________	{{CONTACT_EMAIL}}	{{PHONE}}
Reconesys alternate	______________	{{CONTACT_EMAIL}}	{{PHONE}}

How to stop us. Call or message the Reconesys engagement lead and say “stop”. You do not need to explain, and nothing is invoiced differently for it. We will confirm in writing within one hour that activity has ceased.

If you cannot reach us, block the source addresses listed in Part F. We will not treat that as an obstruction, and we will not attempt to work around it — a block is a stop instruction expressed in firewall rules.

Part H — What the Customer confirms

The Customer confirms, and the signatory in Part L confirms on the Customer’s behalf, that:

Ownership or control. The Customer owns or lawfully controls every asset listed in Part C.
Authority. The signatory has authority to bind the Customer and to give this authorisation. [COUNSEL: tell us what to require as evidence — a board resolution, a director's signature, a letter of authority, or the signatory's own statement. Our concern is a middle manager signing something the organisation later disowns, which would leave us having connected to a hospital's systems with no valid authority. What is the least burdensome thing that actually protects us?]
No conflicting obligation. This authorisation does not breach any agreement binding on the Customer, including any hosting, cloud, payment-processing or franchise agreement.
Third-party permission. Where Part C.5 applies, the necessary provider permission is in place.
Internal notification. The Customer has told the people who need to know — its IT team, its provider, and anyone monitoring its systems — that authorised activity will occur in this window.
Backups. The Customer has current backups of anything in scope. We do not intend to change anything, but connecting to a live system is never entirely without risk, and the honest thing is to say so before rather than after.
Accuracy. The information in Parts A to G is accurate and complete to the best of the Customer’s knowledge.

Part I — What Reconesys undertakes

We will stay inside the scope. Only the assets in Part C, only the techniques ticked in Part D, only within the window in Part E.
We will stop when told, by anyone using Part G, without asking why.
We will not exploit, modify, or extract. See D.2. Where we find exposed data, we record enough to prove it and no more.
We will keep it confidential. Findings about your business are yours. We will not publish them, name you, or use them in marketing. If we ever encounter something with wider public consequences, the route in Kenya is the national incident response team, KE-CIRT, and we will tell you before we tell them.
We will keep evidence securely, and delete it on the schedule in privacy-policy.md, or sooner if you ask.
We will tell you promptly if anything goes wrong on our side — if we touch something outside scope by mistake, if a system becomes unstable during our activity, or if we lose control of any evidence. Immediately, in writing, without waiting for the report.
We will not subcontract any part of this work without your written agreement.
Our people are bound. Everyone who performs work under this form is under a written confidentiality obligation to us.

Part J — Data protection

If performing the checks means we handle personal data on the Customer’s behalf — for example if an in-scope system returns data belonging to your patients, guests or staff — then in respect of that data the Customer is the data controller and Reconesys is the data processor, and the processing terms in Schedule 1 apply.

[COUNSEL: draft Schedule 1 as a data processing agreement satisfying section 42 of the Data Protection Act 2019 (verify the section) and the General Regulations 2021, covering: subject matter and duration; nature and purpose; types of personal data and categories of data subject; the processor's obligations; sub-processing; security measures; assistance with data-subject rights and breach notification; deletion or return on completion; and audit. We have left it as a placeholder rather than draft it badly.]

For the personal data the Customer’s own staff give us in the course of the engagement — names, work email addresses, telephone numbers — Reconesys is the controller and privacy-policy.md applies.

Part K — Variation, revocation and survival

Variation. Any change to Parts C, D or E must be agreed in writing by both parties and appended as a numbered variation to this form. An email exchange between the named contacts is sufficient writing, provided it states the form reference and quotes the change. Nothing else varies this form.
Revocation. The Customer may revoke this authorisation at any time, in whole or in part, by notice to the Reconesys contacts in Part G. Revocation takes effect the moment it is received. We will confirm in writing.
Expiry. This authorisation expires at the end of the window in Part E, whether or not the work is finished.
Survival. Parts I.4, I.5 and J survive expiry or revocation.

Part L — Signature

Signed for and on behalf of the Customer by a person with authority to bind it:

Field	Value
Full name	________________________________________
Position held	________________________________________
I confirm I have authority to bind the Customer named in Part A	[ ] Yes
Signature	________________________________________
Date	________________________________________
Place	________________________________________

Signed for and on behalf of {{LEGAL_ENTITY}}:

Field	Value
Full name	________________________________________
Position held	________________________________________
Signature	________________________________________
Date	________________________________________

[COUNSEL: advise on execution formalities — whether a witness or a company seal is required for this to bind a Kenyan company; whether an electronic signature is sufficient under the Kenya Information and Communications Act and the Business Laws (Amendment) Act 2020, and if so what kind (a typed name, a scanned signature, or an advanced electronic signature); and how long we must retain the executed form. We would like to accept electronic signature if we lawfully can, because requiring a wet signature from a hospital administrator will cost us days on every engagement.]

Attachments

Asset list, where Part C is too long for the tables
Evidence of third-party provider permission (Part C.5)
Evidence of the signatory’s authority (Part H.2)
Schedule 1 — data processing agreement, where Part J applies
Variations, numbered, in date order

Variation log

No.	Date	What changed	Agreed by (Customer)	Agreed by (Reconesys)
1
2