Forever Works
Legal · 06

Security and disclosure.

Our whole practice is about making change safe, so a report that we got something wrong is useful to us rather than unwelcome. Here is how to send one, what we promise in return, and the ground rules that keep both sides out of trouble.

Last updated 6 August 2026Issued by FOREVER WORKS S.R.L.CUI 45079498

01Reporting a vulnerability

Email hello@foreverworks.com with SECURITY in the subject line. Please include what you found, where, and the minimum steps to reproduce it. Please do not post it publicly before we have had a chance to fix it.

Preferred language
English or Romanian
Acknowledgement
Within two working days
Assessment
An initial assessment and a remediation plan within ten working days
Credit
Named publicly if you want it, and never without your agreement

02What we commit to

  • We will acknowledge your report and keep you informed as it is worked.
  • We will not pursue legal action, or ask anyone else to, for good-faith research that follows the rules in section 3.
  • We will fix what is genuinely a vulnerability, prioritising by real impact rather than by scanner severity.
  • Where a finding affects a client system, we will pass it to that client promptly and respect their disclosure process.
  • We will tell you when it is fixed, and agree the timing of any public write-up.

We do not operate a paid bug bounty. What we offer is a fast, honest response and public credit if you want it.

03Ground rules

Research is welcome within these limits, which exist to protect other people:

  • Stay on systems we operate: www.foreverworks.com and its subdomains, and software published under the Forever Works name. Client systems are explicitly out of scope, even when we built them; report those to us and we will route them.
  • Do not run denial of service, volumetric or load testing, and do not send automated traffic that degrades the service for others.
  • Do not access, modify or exfiltrate data that is not yours. If you stumble into personal data, stop, tell us, and delete anything you retrieved.
  • No social engineering, phishing or physical intrusion against the company, its people or its suppliers.
  • Use your own test accounts and data, and leave systems as you found them.

Reports of missing best-practice headers, weak TLS cipher preferences, or output from a scanner with no demonstrated impact are read, but they are not treated as vulnerabilities.

04How we work

The way we build is itself a security control, and it is the same discipline the case files on /work describe.

  • Change goes through a gate. Work reaches production through a reviewed, recorded change, and it can be rolled back to a known-good state.
  • The client holds the keys.Everything we build ships in the client's own repositories and accounts, so access is theirs to grant and theirs to revoke.
  • Least privilege. Access is limited to the people who need it, protected by unique credentials and multi-factor authentication.
  • Minimal data. We prefer engagements where we never hold production personal data at all, and we work against anonymised or synthetic data where we can.
  • Dependencies. The site and our tooling track upstream releases, and security updates are applied rather than deferred.

05Personal data breaches

If a report involves personal data, our obligations under the GDPR apply: where we are the controller we notify the Romanian supervisory authority within 72 hours of becoming aware of a notifiable breach, and we inform affected people where the risk to them is high. Where a client is the controller, we notify that client without undue delay so they can do the same. The detail is in the Privacy Policy.

← All legal documents← Back to foreverworks