Security Practices

1. Personnel onboarding and offboarding

ScoutSocial limits production access to personnel who require it for their role. All credentials and access rights are revoked promptly on departure. We are formalising onboarding and offboarding procedures, including data-protection awareness and access documentation, on an ongoing basis.

2. Access Controls

Access to production systems and Customer Personal Data is granted on a least-privilege, role-based basis: distinct roles for engineering, customer support, security and operations, each with documented data-access scope. Staff access to Customer data is logged in an immutable audit trail (actor, action, resource, timestamp, ticket reference) and is reviewable on request. ScoutSocial uses exactly one (1) Google Cloud API Project for its YouTube API Client; YouTube API credentials are stored in our secrets manager, are accessible only to authorised personnel under confidentiality obligations, and are never embedded in any open-source project.

2.1 OAuth token handling

Connected-Platform OAuth access and refresh tokens are stored encrypted at rest using AES-256 envelope encryption (AWS KMS), are decrypted in memory only at the moment of an API call, are not exposed to the browser client, and are scoped to the workspace that authorised them — never shared or pooled across workspaces or users. Tokens are decrypted only within the publishing and sync code paths; they are never logged in plaintext and are not accessible through administrative or customer-support tooling. Tokens are deleted when the user disconnects the account, leaves the workspace, or revokes ScoutSocial’s authorisation at the Connected Platform; deletion propagates to all active systems, replicas and caches within 7 days, and copies held in encrypted backups are overwritten on the standard backup-retention cycle.

3. Encryption

Encryption in transit. All ScoutSocial endpoints accept only TLS 1.2 or higher; HSTS is enabled for the production domain. Internal service-to-service traffic uses mutually authenticated TLS or runs within a private VPC. All Meta Graph API calls are HTTPS-only and include appsecret_proof where Meta requires it; OAuth tokens are never exposed to the browser client. Encryption at rest. Customer Personal Data, including OAuth access and refresh tokens and content media, is encrypted at rest using AES-256 envelope encryption with keys managed in AWS KMS. Customer Personal Data in logs is redacted or hashed before storage where feasible.

4. Monitoring and Logging

Monitoring.Production systems are continuously monitored through our cloud provider’s native monitoring service, with automated alarms covering infrastructure health (compute, memory, database capacity and connection load, cache utilisation), elevated server error rates, and unhealthy service instances. All inbound traffic passes through a managed web application firewall running vendor-maintained rule sets for common web attack patterns and known-bad inputs, together with per-IP rate limiting; a sustained spike in blocked requests raises an automated alarm. Application-level rate limits additionally protect authenticated endpoints on a per-workspace basis. Application exceptions in the API and background-job workers are captured by an error-monitoring service, with tokens, credentials and other sensitive values scrubbed from every event before it leaves our systems.

Alerting. Automated alarms are delivered to designated operations personnel and triaged under the incident-response process described in § 7.

Audit logging. In addition to the staff-access log described in § 2, we maintain: (i) API request logs recording the endpoint, authenticated user, outcome and timing of every request, with client IP addresses truncated at the point of capture for data minimisation; (ii) a per-workspace activity log of user and administrative actions; (iii) cookie-consent and privacy-choice receipts, including Global Privacy Control signals; and (iv) network-level access logs to support incident forensics.

Retention.Security-relevant application logs are retained for at least thirty (30) days and network access logs for thirty (30) days, after which they are deleted automatically. Error-monitoring events are retained per the sub-processor’s standard retention schedule.

5. Backup and Recovery

The primary application database is backed up automatically every day, with continuous transaction-log archiving that supports point-in-time recovery at approximately five-minute granularity within a seven (7)-day retention window; a final snapshot is always taken before any database instance is retired, and deletion protection is enabled. Database backups inherit the database’s AES-256 encryption at rest under an AWS KMS key. Content media in object storage is versioned, retaining prior versions of overwritten or deleted objects for thirty (30) days as a recovery window, and is stored redundantly across multiple availability zones with server-side AES-256 encryption. Our production infrastructure is defined entirely as code, allowing the environment to be re-provisioned in a repeatable way as part of recovery. Recovery procedures for platform-level incidents are documented in internal runbooks and are exercised and refined as part of our incident-response process (§ 7).

6. Secure Development

Security considerations are incorporated into development, testing, and release processes for new features and updates. We implement platform-specific error handling, retry and backoff behaviour for each Connected Platform API, and surface persistent errors to users via in-product alerts.

6.1 API integration discipline

ScoutSocial: (a) tracks each Connected Platform’s pinned API version against the Connected Platform’s current and deprecated versions and plans regression-tested upgrades before each pin’s deprecation deadline (Meta Graph API deprecates on a ~2-year cycle); (b) subscribes to each platform’s developer-policy and revision-history channels (YouTube Required Minimum Functionality RSS, Meta developer newsletter, LinkedIn pre-notification process, X developer changelog, TikTok developer announcements) so that integration changes propagate within each platform’s required window; (c) accesses Connected Platform APIs only through documented endpoints — undocumented APIs, scraping and reverse-engineering are prohibited.

6.2 OAuth scope minimisation

ScoutSocial requests only the OAuth scopes its current features require, requests scopes incrementally where a platform supports incremental authorization, and exercises each requested scope within 28 days to avoid Meta’s silent permission-suspension rule. Aspirational or future-proofing scope requests are not made.

6.3 Audit cooperation

ScoutSocial cooperates with all platform audits and monitoring activities. On request and within the platform’s stated timeframe we provide test accounts that exercise the current production feature surface, documentation of scopes, retention and deletion flows, and proof of compliance with the platform’s developer policies. Quota-extension requests with YouTube trigger an API Compliance Audit which we resource and respond to in full.

7. Incident Response

ScoutSocial maintains a documented incident-response process covering identification, containment, eradication, recovery, Customer and regulator notification, and post-incident review. Customers will be notified of any Personal Data breach affecting them without undue delay and no later than 72 hoursafter we become aware of the breach (consistent with GDPR Art. 33). Where a breach involves Connected Platform Data we additionally notify each affected platform within its required timeframe and through its required channel — including: LinkedIn— written report to security@linkedin.com within 24 hours of discovery, and no public statement until LinkedIn has granted written permission; Meta— submission via Meta’s developer incident form as soon as practicable; YouTube/Google— notification to the API Services contact form. Post-incident reports are produced and retained in accordance with our retention schedule.

8. Updates

We may update these practices over time to reflect legal requirements and improvements in security controls.

9. Vulnerability Reporting

Security researchers and Customers can report suspected vulnerabilities to legal@scoutsocial.ai or via the disclosure contact published at /.well-known/security.txt.

Scope. In-scope systems include scoutsocial.ai and its subdomains, the ScoutSocial web application, and our API endpoints. Out of scope: the social platforms we integrate with (report those directly to the relevant platform), denial-of-service testing, physical security, and social engineering attacks.

Rules of engagement. Please do not access, modify, or delete data belonging to other users; do not disrupt production services; and do not publicly disclose a vulnerability before we have had a reasonable opportunity to address it.

Response timelines. We aim to acknowledge receipt within 3 business days and to provide an initial triage assessment within 10 business days. We will keep you informed of progress and notify you when the issue is resolved.

Safe harbour. ScoutSocial will not pursue legal action against researchers who discover and report security vulnerabilities in good faith and in accordance with these guidelines.

ScoutSocial will also report third-party non-compliance with platform developer policies (e.g. a sub-processor or Customer attempting prohibited actions) back to the affected platform through its API Services contact form or equivalent.

10. General Contact

Questions about security practices: legal@scoutsocial.ai