Security

1. Scope

This page covers:

• The public website at vedatra.com, including Insights
• The operator CMS used to publish Insights and read contact submissions
• Responsible disclosure for Vedatra-operated products described on the Site, including Watchio and Callfora, unless a product notice says otherwise
• How we treat access to a client estate during an engagement

It does not authorise testing of a client’s production systems. Those systems are out of scope unless that client has given you written permission.

2. How We Protect the Website

The public Site is a marketing and Insights surface plus a contact form. Controls include:

• Transport security with HTTPS/TLS
• Admin authentication via an httpOnly session cookie with a 24-hour lifetime
• CMS and contact records limited to authorised operators
• Sanitisation of Insights HTML and validation of form input
• A honeypot and rate limits on public endpoints to absorb automated abuse
• Separation of the public Site from client production estates — an enquiry does not grant anyone access to another organisation’s systems

3. How We Protect Engagements

When we are on a client estate, access is treated as temporary and named.

• Access is requested only for the work in the statement of work
• We use identities the client provisions wherever we can, rather than shared passwords
• Secrets are not sent through the public contact form
• Least privilege: the role matches the task, not a standing admin grant
• Handover is written. Access is withdrawn at exit unless you have asked us to keep operating the system
• Client names and estate detail stay under NDA when the contract requires it

Security findings we produce in an engagement belong in the engagement record. They are not published on the Site.

4. Responsible Disclosure

If you discover a security vulnerability in vedatra.com, the CMS, or a Vedatra-operated product, please report it to us privately. Do not post an exploit, a proof of concept against a live client, or credentials in a public channel until we have had a reasonable chance to fix the issue.

Email hello@vedatra.com with the subject line “Security disclosure”. Include a clear description, the affected URL or component, and evidence that does not put other people at risk. Do not request or use another person’s data to prove the issue.

1. 24 hoursAcknowledgment

   We confirm we have received the report.

2. 72 hoursTriage

   We assess severity and start remediation if the report is valid.

3. OngoingResolution

   We keep you updated until the issue is closed or we explain why we will not change it.

We do not currently run a paid bug-bounty programme. We will thank researchers who report in good faith and, where it is safe, tell you when the fix is live.

5. What We Ask You Not to Do

The following is not authorised, even if you intend to file a report afterwards:

• Denial-of-service or traffic floods against vedatra.com or a client
• Social engineering of Vedatra people or of a client’s staff
• Accessing, copying, or changing data that is not yours
• Physical attacks on offices or hosting facilities
• Testing a client production system without that client’s written permission
• Public disclosure before we have responded, except where the law requires you to notify a regulator

6. Client Systems

If you found an issue in a system we built or operate for a client, tell us and, if you can do so safely, tell the client. We will not treat a good-faith report of that kind as a hostile act against Vedatra.

We cannot authorise you to test a client’s estate. Only that client can.

7. Questions about security

If you need a written note on controls for a procurement or compliance review, or you want to send an NDA before you describe an estate, use the same address. We will say clearly what we can stand behind and what we cannot.