Information Security Policy

1. Purpose and Scope

Social9 is a social media content creation and scheduling service. Customers trust us with their content, their account details, and access to the social media accounts they connect for publishing. This policy sets out how we protect the confidentiality, integrity and availability of that data.

It covers:

• Customer account data, content, media and AI generation history
• Access tokens and profile data received from connected social media platforms
• Production systems, source code, and the third-party services we rely on

2. Governance

• Social9's leadership owns the security program and reviews it at least once a year, and after any significant incident or change to the product.
• A named security lead is responsible for day-to-day security operations, risk assessment and incident response.
• Our controls are designed around recognised frameworks, including the AICPA Trust Services Criteria (security, availability, confidentiality), ISO/IEC 27001 and the OWASP Top 10.
• Security risks are recorded, rated and tracked to resolution.

3. Data Classification

4. Protecting Connected Social Media Accounts

Connecting a social media account gives Social9 the ability to publish to it, so we treat those credentials as our most sensitive data.

• OAuth only. Accounts are connected through each platform's official OAuth flow. We never ask for, receive or store social media passwords.
• Least privilege. We request only the permissions needed for the features a customer uses.
• Encrypted tokens. Access and refresh tokens are encrypted with AES-256 before they are stored, using keys held in a managed key service, separate from the database.
• Restricted use. Tokens are decrypted only by the publishing service, only at the moment they are needed, and never sent to the browser, written to logs, or shared with another customer.
• Exact redirect URIs. OAuth callbacks are registered as fixed HTTPS URLs on app.social9.com, and every flow uses a single-use state value to prevent forgery.
• Prompt revocation. When a customer disconnects an account, we revoke the token with the platform where supported and delete it within 7 days.
• Platform terms. We follow the data use, storage and deletion rules of each platform we integrate with, as described in our Privacy Policy.

5. Encryption

• All traffic to social9.com, app.social9.com and our APIs uses HTTPS with TLS 1.2 or higher. HTTP Strict Transport Security (HSTS) is enabled.
• Customer data, backups and media are encrypted at rest with AES-256.
• Encryption keys are managed in a dedicated key management service, access to them is logged, and they are rotated on a defined schedule and whenever compromise is suspected.

6. Access Control

• Access to production systems and customer data is granted on a least-privilege, need-to-know basis and approved by the security lead.
• Single sign-on and multi-factor authentication are required for all administrative and infrastructure access.
• Staff do not view customer content or connected-account data unless a customer asks us to (for example, to investigate a failed post), for security investigations, or where the law requires it. Such access is logged.
• Access rights are reviewed at least quarterly, and removed within one business day when someone changes role or leaves.
• Within the product, workspace owners control member roles and permissions, and customers can enable multi-factor authentication.

7. Infrastructure and Network Security

• Social9 runs on established cloud providers whose data centres hold independent security certifications. A list of providers is on our Sub-processors page.
• Production, staging and development environments are separated. Customer data is not used in development or testing.
• Traffic passes through a web application firewall with DDoS protection and rate limiting.
• Databases and internal services are not directly reachable from the internet.
• Systems are kept patched; critical security updates are applied as a priority.
• Customer media is served from a dedicated media domain, media.social9.com, separate from the application.

8. Secure Development

• Every code change is reviewed by another engineer before it reaches production.
• Dependencies are monitored for known vulnerabilities, and automated security scanning runs on our code.
• Secrets are stored in a secrets manager, never in source code.
• Engineers follow secure coding practices aligned with the OWASP Top 10, including input validation, output encoding and parameterised queries.
• Changes are deployed through an automated pipeline that can be rolled back.

9. Logging and Monitoring

• Authentication events, administrative actions and access to sensitive data are logged centrally and protected from tampering.
• Logs are monitored with automated alerting for suspicious activity and service errors.
• Logs exclude passwords, tokens and payment card data.
• Security logs are retained for 12 months.

10. Incident Response

We maintain a documented incident response plan that covers detection, triage, containment, eradication, recovery and post-incident review.

• If we confirm a personal data breach affecting customer data, we notify affected customers without undue delay and within 48 hours of confirmation, with the information they need to meet their own obligations.
• Where Social9 is the controller, we notify the relevant supervisory authority within 72 hours where the GDPR requires it, and affected individuals where the risk to them is high.
• If a breach involves data from a connected social media platform, we also notify that platform as its developer terms require, and revoke affected tokens.
• Every significant incident ends with a written review and tracked corrective actions.

11. Business Continuity and Backups

• Production data is backed up daily. Backups are encrypted, stored separately from production, and retained for 35 days.
• Restoration from backup is tested periodically.
• Scheduled posts that fail to publish because of an outage are retried automatically, and customers are told about any post that could not be published.

12. Vendor Management

• Before we use a vendor that will process customer data, we review its security and privacy practices.
• Vendors that process personal data sign data protection terms that meet GDPR Article 28.
• We publish our current sub-processors and give notice before adding new ones, as set out in our Data Processing Addendum.

13. People

• Employees and contractors sign confidentiality agreements before they get access to customer data.
• Everyone completes security and privacy training when they join and every year after.
• Company devices use full-disk encryption, screen lock and up-to-date software.
• Breaches of this policy can lead to disciplinary action, up to termination.

14. Data Retention and Disposal

We keep customer data only for as long as it is needed to provide the service or meet legal obligations, as set out in our Privacy Policy. Customers can delete their data at any time by following our Data Deletion Instructions. Deleted data is removed from backups as the backups expire.

15. Vulnerability Disclosure

If you believe you have found a security vulnerability in Social9, email security@social9.com with a description and steps to reproduce. We acknowledge reports within 2 business days and keep you informed until the issue is resolved. We will not take legal action against good-faith research that:

• Avoids privacy violations, data destruction and service disruption
• Uses only your own accounts, or accounts you have permission to test
• Gives us reasonable time to fix the issue before it is disclosed

Our contact details are also published at /.well-known/security.txt.

16. Contact

Security questions: security@social9.com
Privacy questions: support@social9.com