Security at GiraffyReach

GiraffyReach runs entirely on Google Cloud Platform (GCP). GCP maintains ISO 27001, SOC 2 Type II, PCI DSS, and FedRAMP certifications. Physical security, power redundancy, and hardware lifecycle management are GCP's responsibility under a shared-responsibility model.

All services run inside private VPCs with no direct public internet exposure. Public-facing endpoints are fronted by a load balancer and Cloud Armor WAF. Firewall rules follow a default-deny posture — inbound traffic is allowed only on explicitly approved ports and protocols.

Production, staging, and development environments are isolated in separate GCP projects with separate service accounts and IAM policies. No developer has standing access to production data. Access to production requires a temporary elevation through a formal approval workflow, and all actions are logged.

Cloud Armor provides always-on volumetric DDoS protection at the network and application layers. Rate limiting is enforced at the API gateway level. Adaptive protection monitors traffic patterns and automatically adjusts rules in response to detected attacks.

All communication between clients and GiraffyReach servers uses TLS 1.2 or higher. TLS 1.0 and 1.1 are disabled. We enforce HTTP Strict Transport Security (HSTS) with a 1-year max-age and include subdomains. Internal service-to-service communication within the VPC also uses TLS.

All stored data — databases, object storage, and backups — is encrypted at rest using AES-256. Encryption keys are managed through Google Cloud KMS with automatic rotation on a 90-day cycle. We do not manage raw encryption keys at the application layer.

GiraffyReach never stores, processes, or transmits raw payment card numbers. All payment processing is handled exclusively by Stripe, a PCI DSS Level 1 certified provider. We store only Stripe-issued tokens that cannot be used to reconstruct the original card details.

When you connect a Gmail or Outlook account for automated outreach, we store the OAuth refresh token — never your password. Tokens are encrypted at rest using a separate KMS key and are scoped to the minimum permissions required (send-only where available). Access to raw tokens is restricted to the automated outreach service and is logged on every use.

We collect only the data necessary to operate the features you enable. Resume and profile data is stored in our primary database. Job activity data is stored in a data warehouse for analytics. Both are access-controlled and subject to our data retention policy — see the Privacy Policy for full details.

MFA is mandatory for all GiraffyReach employees accessing internal systems. User accounts support MFA via authenticator apps. We strongly recommend enabling MFA on your GiraffyReach account — it can be configured in account settings.

Employee access to systems and data is scoped to what is necessary for their role. Access rights are reviewed quarterly. When an employee changes roles or leaves the company, access is revoked within 24 hours. Service accounts are assigned the minimum IAM roles required to perform their function.

No engineer has standing access to production databases. Elevated access is granted on a just-in-time basis through our PAM workflow, requires manager approval, and is automatically revoked after a time-limited session. All privileged sessions are recorded and auditable.

All internal tools are accessed through our corporate SSO provider with SAML 2.0. Direct login to internal tools using local credentials is disabled. SSO sessions enforce idle timeout and require re-authentication after 8 hours.

Security is integrated into our development process. Code changes undergo peer review before merging. Automated static analysis runs on every pull request. Dependencies are scanned for known vulnerabilities using automated tooling with daily database updates.

We design and test against the OWASP Top 10. Specific controls include: parameterized queries to prevent SQL injection; output encoding to prevent XSS; CSRF tokens on all state-changing requests; Content Security Policy headers; and strict input validation on all API endpoints.

All API endpoints require authentication. Requests are validated against a defined schema — malformed requests are rejected before reaching application logic. Rate limiting is enforced per user and per IP. Authentication tokens expire and must be refreshed — long-lived tokens are not issued.

Third-party dependencies are tracked in a software bill of materials (SBOM). Automated alerts notify our engineering team when a dependency has a reported CVE. Critical vulnerabilities are patched within 24 hours; high-severity vulnerabilities within 7 days.

We operate continuous monitoring across application logs, infrastructure metrics, and security events. Anomaly detection alerts are triaged by our on-call engineer 24/7. Our target mean time to detection (MTTD) for high-severity incidents is under 24 hours.

When an incident is confirmed, we follow a documented runbook: contain the incident, assess scope and impact, eradicate the root cause, recover affected systems, and conduct a post-mortem. Incidents are classified by severity (P0–P3) which governs response time and escalation path.

In the event of a security incident that affects your personal data, we will notify you within 72 hours of confirming the breach — as required by GDPR Article 33 and applicable US state laws. Notifications will include: what happened, what data was affected, what we have done to contain it, and what steps you can take.

Every P0 and P1 incident results in a blameless post-mortem within 5 business days. Post-mortems identify root cause, contributing factors, and specific corrective actions with owners and deadlines. We track open action items to completion.

Database backups run automatically every 6 hours. Backups are stored in a geographically separate GCP region with the same AES-256 encryption as primary storage. We retain daily backups for 30 days and weekly backups for 90 days.

Our target Recovery Time Objective (RTO) for a full database restore is 4 hours. Our target Recovery Point Objective (RPO) — the maximum data loss in a disaster scenario — is 6 hours. These targets are tested annually through planned recovery exercises.

GiraffyReach is designed for high availability using multi-zone deployments within GCP. Planned maintenance is performed during low-traffic windows and announced in advance via our status page. Unplanned outages are communicated in real time.

Before onboarding a new vendor with access to customer data, we assess their security posture — including reviewing their SOC 2 report or equivalent, data processing agreement, and breach notification procedures.

All vendors who process personal data on our behalf sign a Data Processing Agreement (DPA) that binds them to GDPR-equivalent data protection standards, regardless of where they are located.

Our primary sub-processors with access to personal data include Google Cloud Platform (infrastructure), Stripe (payments), and transactional email providers. A complete and current list of sub-processors is available on request at support@giraffyreach.com.

We welcome security researchers who responsibly disclose vulnerabilities. If you discover a potential security issue in GiraffyReach, please report it to support@giraffyreach.com with: • A description of the vulnerability and its potential impact. • Steps to reproduce the issue. • Any proof-of-concept code or screenshots (do not include live customer data). We will acknowledge your report within 2 business days and provide a status update within 10 business days.

We will not take legal action against researchers who: discover vulnerabilities in good faith, do not access customer data beyond what is necessary to demonstrate the issue, do not disrupt our services or other users, and report the vulnerability to us before public disclosure.

In scope: giraffyreach.com and all subdomains, our API, and our mobile web experience. Out of scope: third-party services, physical security, social engineering, and denial-of-service testing.