Security

Last updated 17 October 2026

How we protect your business data

You’re handing us a list of the businesses you watch. That list is commercially sensitive, and in the white label programme it is your client book. Here is exactly how it is handled.

• Encrypted in transit. All traffic runs over TLS 1.3.
• Encrypted backups. Database backups are GPG-encrypted on our server before they are uploaded anywhere, so the storage provider never holds readable data.
• We don’t sell or share it. Your business list and your briefs are not sold, rented, or shared with other customers.
• Your data doesn’t live forever. Retention limits are enforced automatically on a schedule, not by hand — and you can delete your account and its data at any time.
• What we monitor is public. The intel in your briefs comes from publicly available sources. We do not access anything private belonging to the businesses you track.

Who else handles your data

A small number of outside services help run MyIntelBrief. Each one is contractually bound to use your data only to provide its service to us. All of them are US-based and process data in the United States.

• AI language-model providers — write and check the briefs. They see the business names, websites and public information needed for a brief. They don’t train their models on it.
• Public-web research and business-listing providers — find public information about the businesses you watch. They see the names and locations being looked up.
• Email delivery — sends briefs and account email. Sees recipient addresses and the email content.
• Payments — handles billing. Card numbers go straight to the payment processor; we never see or store them.
• Hosting — a dedicated server we run ourselves. The host has physical access to the hardware, not logical access to application data.
• Off-site backups — encrypted on our server before upload, so the storage provider never holds readable data.
• Site analytics and bot protection — see how pages are used and keep automated abuse off our forms. Password fields are masked; admin pages are excluded.

• Your client list is never used to train AI models — not by us and not by our providers. When you report an error in a brief, we write up what went wrong and add it to the instructions the system follows; your data itself isn’t used as training data.
• New kinds of provider: we email active subscribers at least 30 days before adding a new category of provider.
• Need it in writing? White label and Enterprise customers can sign our Data Processing Agreement (PDF): sign it and email it to info@myintelbrief.com. No call needed.

Full detail on what we collect, why, and how long we keep it is in the Privacy Policy. Questions we haven’t answered here? Ask us — we’d rather answer than have you guess.

Report a vulnerability

If you have found a vulnerability that affects our service or our customers' data, we want to hear about it — and we'd rather hear about it from you than find out the hard way.

Our policy

• We do not pay bounties. We have no paid bug-bounty programme and no budget for one. We will not negotiate a payment in exchange for the details of a report. If that is a dealbreaker for you, please don't spend your time — we'd rather be straightforward about it up front than waste yours.
• We will not respond to reports that withhold the finding. A message saying a vulnerability exists but declining to describe it until we reply, agree to terms, or discuss compensation is not a security report, and we won't engage with it. Send the details or don't send anything.
• We read every report that includes reproduction steps, and we investigate the ones that check out. We're a small team, so we don't guarantee a response time, and we may not reply to reports we can't reproduce or that describe no real impact.
• Credit, if you want it. If you report something real and you'd like to be acknowledged publicly, tell us and we'll be glad to name you once it's fixed.

What we consider out of scope

Automated scanner output with no demonstrated impact is generally not actionable for us. That includes, unless you can show a concrete exploit:

• Missing or “weak” HTTP security headers
• SPF / DKIM / DMARC configuration opinions
• Missing rate limits with no demonstrated abuse
• Software version fingerprinting, banner grabbing, or “outdated library” reports without a working exploit
• Self-XSS, clickjacking on pages with no sensitive action, or issues requiring a fully compromised device
• Denial of service, volumetric testing, or anything that degrades service for real users

Testing boundaries

Please test only against your own account and your own data. Do not access, modify, or retain another customer's information; do not run denial-of-service or load tests; and do not use social engineering against our staff or our customers. If you encounter someone else's personal data during testing, stop, don't save it, and tell us what happened. We won't pursue action against anyone who follows these boundaries and reports in good faith.