Security

Your search, protected.

Every credential, every draft, every conversation. Handled with the care we'd want for our own careers.

How we think about your data

Three principles we hold ourselves to.

They aren't features you can toggle. They're the default posture of the service — the shape of every decision we make about the information you hand us when you start a search.

Principle 01

Least data by default. We only collect what your strategist needs.

Your strategist runs a real search on your behalf, and that job has a shape. They need enough of your background to write in your voice, enough of your target to source the right roles, and enough of your calendar to hand a recruiter a real time to talk. Nothing beyond that shape belongs in our system.

We don't ask for a Social Security number, a passport scan, a bank account, or a photo of a government ID. We don't attach a hidden tracking pixel to your résumé. Every optional field on our onboarding form stays optional, and skipping it never downgrades the work.

Optional stays optional · no dark-pattern collection · no shadow profiles

Principle 02

Encrypted in transit and at rest. Every byte.

Every connection between your browser and Marqee runs over TLS 1.3 with modern ciphers and HSTS. Every byte we store — the draft résumé, the coaching notes, the recruiter thread, the file you dropped in chat last Tuesday — is encrypted at rest with AES-256, on managed storage that our infrastructure team never handles in the clear.

Backups inherit the same encryption. Snapshots inherit the same encryption. Anything that leaves our production perimeter for an operational reason — logging, monitoring, disaster-recovery replication — stays encrypted the whole way.

TLS 1.3 · AES-256 at rest · encrypted backups & DR

Principle 03

Human review of every access. No bulk queries on member data.

A strategist reads your file because they own your search. Nobody else reads it as a matter of course. There is no analyst running a query across all members to see what the "average onboarding" looks like, no marketer pulling a dashboard segmented by résumé phrase, no engineer casually browsing production data with a psql shell open.

Every member-data access — whether a strategist opening your file or an engineer touching a row for a support case — leaves an audit log with a timestamp, an actor, and a reason. We review those logs. If something looks off, we call it out ourselves before you have to ask.

Scoped, logged, reviewed · no bulk member queries · reason required

Where your data lives

US hosting, encrypted end-to-end.

Nothing here is a marketing shorthand for something more complicated. The specifics below are the whole picture, and they don't drift when we hire, scale, or ship a new feature.

Primary region

AWS `us-east-1` (N. Virginia).

Production runs on Amazon Web Services in the United States. Multiple availability zones inside the region, so a single-zone incident doesn't take your account offline. All member data stays in-country.

Disaster recovery

AWS `us-west-2` (Oregon).

Encrypted replication into a second US region for disaster recovery. Same posture, same encryption. Recovery-point and recovery-time objectives are documented internally and tested on a rolling schedule.

Encryption

AES-256 at rest · TLS 1.3 in transit.

Envelope encryption on managed storage. Keys are held in AWS KMS with scoped IAM policies and rotation on a documented cadence. Modern cipher suites only; HSTS with preload on marqee.com.

Segmentation

Production is its own perimeter.

Production, staging, and analytics live in separate accounts with separate networks. Staging never gets a copy of production data — the fake data engineers work against is generated, not imported.

Backups

Encrypted, versioned, tested.

Daily snapshots retained on a rolling window; restore drills run on a schedule so the runbook isn't the first time we've read it. Deleted data is purged from backups on the same clock as production, not held forever "just in case."

Analytics

Aggregate only, no raw exports.

Business analytics look at counts, cohorts, and funnels — never at the content of a résumé, a chat message, or a recruiter thread. There is no path that lets an analyst pivot from a dashboard into a member's file.

Access controls

Least-privilege for staff. Hardware-keyed for admins.

Who can reach what, on which terms. Written the way we'd want an auditor to be able to skim it — and the way we'd want to explain it to a family member who asked how their info was handled.

Least privilege

Staff see only the members they own.

Your strategist sees your file because they own your search. Nobody else on the team is granted standing access to it. Support, engineering, and operations see member data only when a specific member-initiated case pulls it into their queue, and only for the scope of that case.

Hardware-key SSO

Every admin login is behind a hardware key.

Marqee staff sign in through single sign-on backed by a phishing-resistant hardware key (WebAuthn / FIDO2). No SMS second factors, no push-notification prompts that fatigue into a "yes." Sensitive admin actions require re-verification even after sign-in.

Quarterly access reviews

We remove access as fast as we grant it.

Every quarter we review who has access to what and revoke anything that no longer maps to someone's current job. Role changes and departures kick off a same-day off-boarding checklist; nothing gets to linger under a former job title.

Audit logging

Every member-data read is logged.

When any staff member opens a member's file, the read lands in an append-only audit log with the actor, the timestamp, and the reason. We sample and review those logs; you can request a report of accesses on your own account and we will produce one.

Credentials handling

Passwords you share are not passwords we see.

Some members ask us to run outreach or apply from inside a platform where they already have a presence. The way we handle those credentials is stricter than the way most people handle their own.

Sharing platform credentials is optional. Every part of the service works without it — we can run outreach from Marqee-side channels, coach you through applications you submit yourself, and coordinate every step in chat. Nothing you're paying for is gated behind handing us a password.

When you do choose to share credentials — for a professional network, a recruiter platform, or an application portal you'd rather not touch this week — they're stored inside a hardware-backed vault (HSM-fronted secret storage). Your strategist never sees the raw value. When a session is needed on your behalf, the vault mints a scoped session and the strategist works inside it. When they're done, the session ends.

What that means in practice:

Your credentials are stored encrypted, keyed to your account, and readable only by the vault — not by our staff, not by our engineers, not by our support tools.
Every use of a stored credential leaves an audit line: which strategist, at which time, for which action.
You can revoke a stored credential any time, from Settings or by asking your strategist in chat. Revocation is immediate; there is no queue or business-day delay.
We recommend a unique password per platform and, wherever the platform supports it, an application-specific token instead of your primary password.

Third-party sub-processors

A short list, held to the same posture.

We use a handful of vendors to run the service — hosting, email delivery, error monitoring, billing, and so on. We keep the list short on purpose, and we hold every vendor on it to the same standard we hold ourselves to.

Least data

Vendors get the narrowest slice they need.

An email vendor sees a send address and a template, not your résumé. An error monitor sees a stack trace, not the content of the field that produced it. If a vendor doesn't need your data for their job, they don't get it.

Contract-mandated

Encryption and non-use are in the paper.

Every sub-processor is bound by a data-processing agreement that mandates encryption in transit and at rest, prohibits use of member data for training or for any purpose beyond delivering the service they're contracted for, and requires breach notification to us within a defined window.

No training use

Your data does not train anyone's model.

No vendor we work with is permitted to use member content — résumés, chat, drafts, notes — as input to train a general model. Where a vendor's default terms would allow that, we're on a plan or a contract line that disables it, and we verify.

Public list

The list itself is public.

You don't have to file a request to see who we work with. The current roster lives at /sub-processors, along with what each vendor does and where they're hosted. Material changes are announced with 30 days' notice.

Vulnerability disclosure

If you find something, we want to hear about it.

Security researchers and members alike are welcome to poke at our surface and tell us what breaks. We take reports seriously and we treat the people who send them like collaborators, not threats.

Our machine-readable disclosure policy lives at /.well-known/security.txt in the standard format. It carries our security contact, our PGP key fingerprint, our preferred languages, and the URL you're reading now as the canonical policy.

We follow a 90-day coordinated disclosure window. From the day a valid report lands, we work in the open with the reporter, ship a fix, and — with the reporter's agreement — publish a write-up. Ninety days is a ceiling, not a floor; most reports are fixed and disclosed much sooner.

What we ask of researchers:

Test against your own account, never against other members' data. If your research needs another account, ask us and we'll spin one up.
Don't run destructive tests, denial-of-service, social engineering against our staff, or physical attacks against our offices.
Give us a reasonable window to fix before you publish. We'll give you a real timeline and status updates, not a black hole.

A public hall of fame for security researchers is on the roadmap; we'll credit anyone who helps us fix a real issue and wants their name on the wall.

Incident response

If something goes wrong, we tell you fast.

No firm can promise zero incidents. What we can promise is the shape of our response — how fast we start, how fast we tell you, and how honestly we write it up afterward.

Hour 24

Internal triage within one day.

Any credible signal of an incident — from a monitoring alert, a researcher, a member, or a vendor — kicks off internal triage inside 24 hours. Scope, severity, and containment steps are on paper before the clock ticks over.

Hour 72

Affected members notified within three days.

If an incident affects your data, you hear from us within 72 hours of confirmation. The notice tells you what happened, what data was involved, what we've done about it, and what — if anything — you should do on your side. Written in the same voice we use everywhere else on the site.

Public post-mortem

Material incidents land on the changelog.

For any material incident, we publish a post-mortem on /changelog: the timeline, the root cause, the fix, and what we changed structurally so the same class of failure doesn't happen twice. No hedged language, no vendor-passing.

Always on

Regulators, when the law asks.

Where regulations require notice to a data-protection authority or attorney general, we notify on the required clock. Nothing about our member-notice practice depends on a regulator forcing our hand — the 72-hour member window applies either way.

Independent posture

Working toward the audits that matter.

We'd rather tell you what's true today than name-drop frameworks we haven't earned yet. Here's where we honestly stand.

In progress · Q4 2026

SOC 2 Type 1.

Type 1 evidence collection is underway with a third-party auditor, targeted for Q4 2026. Type 1 speaks to design of controls at a point in time. When the report is issued, we'll share it with members and prospects under NDA on request.

Planned · following

SOC 2 Type 2.

Type 2 covers operating effectiveness of the same controls over a sustained window (typically 6–12 months). We'll begin the observation period the day the Type 1 report is issued, and target Type 2 issuance the following year.

Adjacent posture

HIPAA-adjacent for healthcare members.

Marqee is not a covered entity, and we do not intentionally collect Protected Health Information. For members searching in healthcare, we run the service with a HIPAA-adjacent posture on the surfaces they touch — least-data collection, encrypted storage, audit logging — so nothing about the work forces a member to share PHI to be served well.

Your side of the fence

What you can do, from your account.

Security is a shared surface. Here are the levers you control from inside your dashboard — and the ones we recommend using early, not later.

Enable biometric app lock.

On mobile, turn on biometric unlock for the Marqee app in Settings → Security. Every open of the app requires Face ID, fingerprint, or your device passcode. A glance over your shoulder in a coffee shop no longer costs you the whole thread.

Use a unique email for your search.

Consider a fresh email address — or an aliased one — for the search itself. It keeps recruiter outreach, application receipts, and Marqee messages out of the same inbox where the rest of your life sends you notifications, and gives you a clean archive later.

Review sub-processors quarterly.

Skim /sub-processors once a quarter. It's a short list on purpose, and material changes are announced with 30 days' notice — but a quarterly glance is the fastest way to know what shape the service is running under this week.

Export or delete your data, any time.

Settings → Privacy → Export produces a machine-readable archive of your account (résumé, drafts, chat, application history) inside 72 hours. Settings → Privacy → Delete triggers a full deletion of your account; deletion propagates to backups on the retention clock and is confirmed in writing.

Contact security

Talk to a real person.

For a vulnerability report, a security question about your account, or anything else where "email hello@" isn't quite the right door — write to our security team directly. Encrypted mail is welcome; our PGP key is linked below.

security@marqee.com security.txt PGP key

Response inside one business day · vulnerability reports triaged same-day where feasible

Your search deserves
the same care as your work.

Least data by default. Encrypted end-to-end. Human review of every access. If any of that ever stops being true, we'll say so — in your inbox and on the changelog, clearly.

Start your search → Read the privacy policy