Skip to content

Security Policy & Responsible Disclosure

If you have found a security weakness in something we operate, this page tells you how to report it and what to expect from us. It also sets out the practices we apply across our services, our products, our software, our platforms and our digital services.

Reporting a vulnerability

We would rather hear about a weakness from you than discover it from an incident. Reports are welcome from anyone, including people with no relationship to us.

  1. 1

    Send the report

    Email us with enough detail to reproduce the issue: the affected system, the steps, and what you observed. A proof of concept helps; a video without steps rarely does.

  2. 2

    We acknowledge

    We aim to confirm receipt within 4–8 business hours and to tell you whether we can reproduce the issue.

  3. 3

    We assess and remediate

    We prioritise by realistic impact rather than by scanner severity. We will tell you what we intend to do and give an expected timeframe.

  4. 4

    We confirm resolution

    We will let you know when the issue is fixed, and we are happy to credit you publicly if you would like that and the report was made in good faith.

What we ask of you

  • Give us a reasonable opportunity to fix the issue before disclosing it publicly.
  • Do not access, modify, delete or exfiltrate data that is not yours. If you encounter someone else's data, stop and tell us.
  • Do not degrade availability. Denial of service testing, load testing and resource exhaustion are out of scope.
  • Do not use social engineering, phishing, or physical intrusion against our people or premises.
  • Test only against systems we operate. If a system belongs to a client, tell us and we will route the report; do not test it directly.

Where a report is made in good faith and within these boundaries, we will not pursue or support legal action in relation to the research itself.

Scope

In scope: systems we operate, including our websites, our platforms, our applications and our digital services. This wording is deliberately general so that anything we launch in future is in scope from the day it exists.

Out of scope, unless a report demonstrates a realistic exploit path: findings from automated scanners with no demonstrated impact, missing hardening headers on pages that carry no sensitive function, weaknesses that require an already-compromised device, issues in third-party services we consume but do not control, and reports concerning software versions where no exploitable path is shown.

Rewards

We do not currently operate a paid bug bounty. We do offer acknowledgement, a clear account of what we changed, and a direct line for future reports. If that changes, this page will say so.

Our security practices

Applied across the systems we operate and, where the engagement covers it, the systems we build and administer for clients.

  • Access granted on a least-privilege basis, with individual accounts rather than shared credentials for administrative work.
  • Multi-factor authentication on administrative access, and dedicated service accounts for automated integrations rather than credentials belonging to a named person.
  • Credentials held in a secret store, rotated when exposure is suspected, and never committed to source control.
  • Transport encryption in current form, with administrative interfaces reachable only from defined access paths rather than the open internet.
  • Segmented networks, so that a single compromised device does not reach the whole estate.
  • Logging of administrative activity and authentication failures, retained long enough to investigate something discovered weeks later.
  • Dependency and platform updates on a schedule, rather than in response to an incident.
  • Backups that are tested by restoring them, on the basis that an untested backup is a hypothesis.

No system is immune from compromise. These practices are intended to reduce the likelihood of an incident and to limit what any single failure can reach.

If we suffer an incident

Where an incident affects data we hold or systems we operate for a client, we will notify affected clients without undue delay once we have enough information to be useful, describe what happened and what we are doing, and support any regulatory notification the client is required to make. Where a law imposes a specific notification deadline on us, we meet it.

Contact

Questions about this document can be sent to info@kyconnects.com. We aim to respond to enquiries within 4–8 business hours.

Related documents