← Back to Facultory

Reporting a security vulnerability

Last updated August 3, 2026

Facultory holds faculty work and, in several tools, information about students. If you have found a way to reach data that should not be reachable, we want to hear about it directly and quickly — and we would rather you tell us than prove it at anyone’s expense.

1. How to report

Email borowczak@gmail.com. There is no form and no account needed. If the finding involves data belonging to a specific person or institution, say so in the first line and do not attach the data itself — we will arrange a way to share it safely.

If you believe a report is being ignored, resend it with ESCALATION in the subject line. A silent report is a bug in this process and we would like to know about it.

2. Scope

In scope: the Facultory web application and its API, the public pages served on faculty, department, and institution addresses, the public intake forms (booking, letter requests, senior-design and prospective-student applications, event RSVPs, polls), the sign-in flow, the billing and seat-purchase flows, and the connector endpoints.

Out of scope: findings in third-party services we build on (report those to the provider — Cloudflare, Stripe, Anthropic, and the mail providers all run their own programmes); denial of service and volumetric testing; social engineering of our people or our users; physical attacks; reports that consist only of a missing best-practice header, a scanner’s output, or the absence of a feature, with no demonstrated impact.

3. Rules for good-faith testing

• Use your own account and your own data. Create a second account if you need two parties; do not test against another user’s records.
• Stop at proof. Once you can show access is possible, stop — do not enumerate, download, or retain what you reached.
• Never touch student records. Advisee, letter, prospective-student, rubric, and senior-design data is covered by FERPA. If a flaw exposes any of it, stop immediately, do not read further, and tell us what you saw in the narrowest terms that make the report actionable.
• Do not degrade the service. No load testing, no automated scanning that generates significant traffic, no spam through the public forms or the mailer.
• Give us a chance to fix it before publishing (see below).

4. Safe harbour

If you follow this policy in good faith, we will treat your research as authorised conduct: we will not pursue or support legal action against you, we will not report you to law enforcement over the testing itself, and we will treat the accidental access that honest testing sometimes causes as an accident rather than a breach of our Terms of Service. If a third party brings action against you for work that stayed within this policy, tell us and we will make that authorisation clear.

This protection is ours to give and covers only us. It does not extend to the infrastructure providers listed above, and it does not cover deliberately accessing, retaining, or disclosing another person’s data.

5. What happens after you report

• Within 3 business days — we acknowledge your report and tell you who is handling it.
• Within 10 business days — we give you our assessment: whether we reproduced it, how we rate the severity, and the fix we intend.
• Then — we keep you updated at least every 14 days until it is closed, and we tell you when the fix ships.
• Disclosure — we ask you to hold publication for 90 days from your report, or until a fix ships, whichever comes first. If we need longer we will explain why rather than let the clock run out silently. We are happy to credit you by name in the hardening log, or to keep you anonymous — your choice.

6. If we have an incident

When we confirm that data was accessed by someone who should not have reached it, we notify the affected account holders and, where an institution is involved, its designated contact. Our commitment is notification without undue delay and no later than 72 hours after we confirm the incident, with what we know at the time: what happened, which data was involved, what we have done, and what you should do. We follow up as the picture becomes clearer rather than waiting for it to be complete. Where student education records are involved, we notify the institution so it can meet its own obligations.

7. Rewards

We do not run a paid bug-bounty programme. We do offer public credit, a written thank-you you can cite, and — for findings that materially improve the platform’s safety — a complimentary subscription. We would rather be honest about that than advertise a bounty we cannot fund.