Security & Access
How Vanguard handles your Facebook page and your team's access
The two questions every chief and IT department asks before signing up: what does this thing actually do with our Facebook page, and who can post what? Here's the full answer.
What we ask Facebook for (and what we don't)
When your page admin connects Facebook, Vanguard requests exactly these permissions through Facebook's official OAuth flow:
| Permission | What it lets us do | What it does NOT let us do |
|---|---|---|
| pages_show_list | See the list of pages you administer, so you can choose which one to connect | See pages you don't admin; see any user's personal profile |
| pages_read_engagement | Read likes, comments, and reach on posts Vanguard makes — for your analytics | Read private messages; read content from other pages |
| pages_manage_posts | Create, edit, and delete posts on the page you selected | Post to your personal profile; post to pages you didn't select |
| business_management | Access pages that are managed through Facebook Business Manager (common in larger orgs) | Modify your Business Manager settings or other assets |
We use Facebook Graph API v24.0. Tokens are encrypted at rest in our database and refreshed automatically before expiration. You can disconnect at any time from Settings → Integrations, which revokes our access immediately.
How your team's access works
Vanguard takes a single Facebook connection from your page admin and exposes posting to the rest of your team through Vanguard — not through Facebook directly. This means:
- Your shift captains, PIOs, and volunteer comms folks never need to be added as Facebook page admins to post
- They authenticate to Vanguard (not Facebook) with their own work email
- You can remove their access in Vanguard at any time; their ability to post disappears the instant you do
- They cannot delete your page, change your page settings, lock the page admin out, or take any action on Facebook that Vanguard itself can't take
This is the single biggest governance pain point we hear about: chiefs not wanting to make every part-time PIO a full Page admin, and the common workaround being a shared page-admin password (against Facebook's terms of service, and a real risk when staff leave). Vanguard exists to make that workaround unnecessary.
Roles inside Vanguard
Vanguard has two role tiers per organization:
- Owner — connects Facebook, manages billing, configures auto-post rules and templates, adds and removes team members. Most departments give this role to the chief, deputy chief, or PIO lead.
- User — can view incidents, create and post incident updates, draft posts. Cannot connect or disconnect Facebook, change auto-post rules, or manage billing.
Tenant isolation
Every record in Vanguard — incidents, posts, audit events, integrations, billing — is stamped with the tenant that owns it. Reads start from authenticated tenant context: when a user opens an incident, our system first verifies they belong to that tenant, then resolves the incident's data. A request that tries to fetch another tenant's data is rejected before any data is touched. Even our platform admins, when reviewing tenant data to provide support, do so through a logged and gated path.
Audit and accountability
Configuration changes — auto-post rule edits, post templates, billing events, owner assignments, tenant settings and feature toggles — are written to a tenant-scoped audit log retained for 30 days. Owners can export the full log in CSV or JSON from Settings → Data Export at any time.
Individual Facebook post events are also recorded. Every successful post and every publish failure is logged with the user (or system rule) that triggered it, the page it was published to, the time, and a direct link to the post. Tenant Owners can review the timeline for any incident on the incident's detail page, or export the full audit log as CSV or JSON from Settings → Data Export.
Note: if a post is deleted or edited directly on Facebook (outside of Vanguard), our audit log reflects what Vanguard did, not the current state of the post on Facebook. Facebook is the source of truth for live content; Vanguard records its own actions.
Data we store
The information Vanguard holds about your organization:
- The incidents your team creates and the ones we ingest from PulsePoint and the National Weather Service
- Your selected Facebook Page IDs and an encrypted Page access token
- Your team members' work emails and Vanguard roles (managed through our auth provider, Clerk)
- A one-year audit log of configuration changes, role changes, and post events
We do notstore: resident phone numbers, resident opt-in lists, citizen profile data, your Facebook page password, personal Facebook profiles, or 911 caller information. Vanguard is not a mass-notification platform — we don't operate a citizen contact database.
Where it runs
- Application: Vercel (US regions)
- Database and backend: Convex Cloud
- Authentication: Clerk
- Billing: Stripe
- Error monitoring: Sentry
All five are SOC 2 Type II certified providers. Vanguard itself is not currently SOC 2 certified, but we plan to pursue it as we move upmarket. If your IT department requires it, email security@vanguardalerts.com so we can prioritize accordingly.
For your IT department
We publish a one-page IT reviewer brief covering data handling, encryption, authentication, integration scopes, hosting, and incident response: read the IT brief →. For procurement, security questionnaires, or anything not covered there, email security@vanguardalerts.com. Most IT reviews close in one to two business days for accounts at our price point.
Reporting security issues
If you discover a security vulnerability, please report it responsibly to security@vanguardalerts.com. We take all reports seriously and will respond promptly to investigate and address any confirmed vulnerabilities.