Watchpost Security Policy and Vulnerability Disclosure Policy

Key points

This summary is for convenience. The numbered clauses are the binding text.

1. About this Policy

1.1 This Policy is issued by XYZ Sdn Bhd (Company Registration No. 202601000000) of Malaysia ("Watchpost", "we", "us"). Clauses 3 to 6 summarise how we protect the Watchpost service (the "Service"); clauses 7 to 14 set out our vulnerability disclosure programme.

1.2 This is the Security and Vulnerability Disclosure Policy ("VDP") referred to in our Terms of Service ("Terms", clauses 5.3 and 14.1(i)), Acceptable Use Policy ("AUP", clause 12) and Privacy Policy (clause 11.2). Capitalised terms not defined here have the meanings in the Terms.

1.3 Clauses 3 to 6 describe our practices and are not a warranty that the Service has no vulnerabilities. Our contractual commitments are in the Terms and in Annex B of our Data Processing Agreement ("DPA"). Nothing here limits non-excludable rights (Consumer Protection Act 1999 s.6).

2. Definitions

3. Why we protect the Service this way

3.1 Watchpost holds access to the social media accounts our Customers connect, so we treat security as our first priority. The measures in clause 4 implement our duty, as data controller and data processor, to take practical steps to protect personal data (PDPA s.9; Personal Data Protection Regulations 2013 reg. 6; Personal Data Protection Standard 2015) and, where applicable, GDPR and UK GDPR Art. 32 and the Singapore Personal Data Protection Act 2012 ("SG PDPA") s.24.

4. Our security measures

4.1 Governance. We keep a written security policy approved by our directors and reviewed every year. We keep a record of the staff who can access personal data and remove access when someone leaves or changes role. Staff are bound by confidentiality duties, and every service provider that handles personal data for us agrees to written security terms (PDPA s.9(2)). Our Data Protection Officer can be reached at [email protected].

4.2 Sign-in. We require strong passwords and refuse common or easily guessed ones. We limit repeated sign-in attempts, lock out attackers progressively and alert you by email. We verify email addresses and let you sign out of every device at once.

4.3 Two-factor sign-in. Two-factor authentication ("2FA") with an authenticator app and recovery codes is available to everyone. It is required for Workspace Owners and for our administrators. Sensitive actions, such as changing your email, password or billing details, ask you to sign in again.

4.4 Access control. Roles (Owner, Admin, Editor, Viewer) limit what each Member can do. Each Workspace's data is kept separate from every other Workspace, and we test that separation. Only a small number of named staff have administrative access, always with 2FA. Support access to a Workspace is read-only and limited to its purpose (Terms clause 5.4).

4.5 Encryption. Data travels over encrypted connections (TLS). Platform access tokens and other secrets are encrypted at rest, and are never shown in the Service or written to logs. Backups are encrypted before they leave our servers.

4.6 Application security. We use standard protections against common web attacks, check every request and every uploaded file, and remove location data from uploaded images. Messages we receive from the Platforms and from our payment processor are checked to confirm they are genuine.

4.7 Payments. You enter card details directly into fields provided by our payment processor. Card numbers never reach our servers.

4.8 Servers and backups. The Service runs on servers we operate or control, with physical and network access limited to authorised persons and security updates applied regularly. We take backups automatically, and keep encrypted copies off-site.

4.9 Logging and monitoring. We log security events, such as sign-ins, lockouts, 2FA and role changes, connected-account changes and administrative actions, and we act on alerts. We keep these logs only as long as our Privacy Policy states. Rate limits protect the Service from abuse (AUP clause 11).

4.10 Secure development. We review changes before release and check them for vulnerable components and exposed secrets. We fix serious findings before release.

4.11 Privacy by design. We ask the Platforms only for the permissions your features need. We delete tokens when you remove a Connected Account, limit how long we keep logs, and let you export and delete your data (Privacy Policy sections 10 and 14).

5. Keeping your Account secure

5.1 Please turn on 2FA, use a unique password, give each person their own Account with the lowest role needed, remove leavers and secure your Platform accounts with their own 2FA.

5.2 We will never ask for your password or 2FA codes.

5.3 If you suspect an Account or Connected Account is compromised, log out everywhere, change your password and email [email protected] immediately (Terms clause 5.3).

6. Security incidents

6.1 Our written incident response plan covers detection, assessment of severity, containment (such as ending sessions, revoking Platform access and replacing keys), recovery and review after the incident.

6.2 For a Personal Data Breach we notify as Privacy Policy clause 12 and DPA clause 8 describe: the Personal Data Protection Commissioner within 72 hours, and affected individuals within 7 days after that, where significant harm is likely (PDPA s.12B; Guideline on Data Breach Notification); EU and UK authorities within 72 hours where required (GDPR and UK GDPR Arts. 33–34); the Singapore Personal Data Protection Commission where notifiable (SG PDPA Part 6A); affected Customers within 48 hours where we are their processor; and the Platforms and our payment processor as their terms require.

6.3 Every Personal Data Breach, notifiable or not, is recorded in a register kept for at least 2 years (Guideline on Data Breach Notification; GDPR Art. 33(5)).

7. Scope

7.1 In scope: (a) our website and the Watchpost web application, including sign-in, 2FA and password reset; (b) the flows that connect Platform accounts; (c) the addresses where we receive notifications and data deletion requests from the Platforms and our payment processor; (d) public post preview and media links; and (e) links in our emails, such as invitations.

7.2 We especially want to hear about: exposure of tokens or secrets; access to another Workspace's data; authentication or 2FA bypass; privilege escalation between roles; publishing through a Connected Account you do not control; account enumeration; server-side request forgery; code execution or stored cross-site scripting via uploads; and webhook forgery.

7.3 Out of scope: (a) systems of the Platforms, our payment processor and our other service providers (see the categories on our Sub-processors page), which you should report to them; (b) copies of Watchpost software operated by others; (c) physical or social-engineering attacks; and (d) denial-of-service or volume testing.

7.4 Without demonstrated security impact, we do not treat these as Vulnerabilities: scanner output without a working proof of concept; missing headers or cookie flags; clickjacking without a state-changing action; logout request forgery; self-XSS; open redirects that cannot steal tokens; version disclosure; SPF, DKIM or DMARC settings; and issues only in unsupported browsers.

8. Rules of engagement

8.1 You may create Test Accounts (meeting the Terms' eligibility rules, including the 18+ requirement), connect only Platform accounts you own or may test, use two Test Workspaces to test isolation, and run automated tools within our rate limits. On request, we may give a Test Workspace complimentary Subscription access to test publishing.

8.2 You must not: (a) access, change, delete or keep data that is not yours; if you encounter any, stop, keep only what proves the issue, report it and delete your copy; (b) use another person's Account, session or token, or publish to a Connected Account you do not control; (c) degrade or disrupt the Service; (d) spam, phish or socially engineer our staff, Customers or Platforms; (e) search for, or try to break into, our administrative tools; (f) plant backdoors or malware, make persistent changes or move into other systems; (g) test the Platforms, our payment processor or our other service providers through the Service, or use payment cards you are not authorised to use; (h) publish harmful content (use private visibility where the Platform allows); (i) disclose a Vulnerability before the Disclosure Period ends; or (j) demand payment for a Report or for keeping it confidential.

9. How to report

9.1 Email [email protected] with the subject "Security", in English or Bahasa Malaysia. Do not use public issue trackers, social media or support chat. Do not put secrets or other people's personal data in your first email; if we need them, we will agree a secure way to receive them.

9.2 Include: (a) the affected URL or feature; (b) the issue and its impact; (c) reproduction steps or a proof of concept; (d) your Test Account identifiers; (e) testing times and source IP addresses; and (f) how you want to be credited. Describe, rather than include, other people's personal data.

10. Our response

10.1 We aim to meet these targets. A target pauses while we await information from you.

10.2 Severity starts from the Common Vulnerability Scoring System (CVSS), adjusted for the Service. Anything exposing Platform tokens or another Workspace's data is Critical.

10.3 We will tell you when the issue is fixed. For duplicates, the first complete Report counts.

10.4 Disclosure. Keep the details confidential until we confirm a fix or 90 days after your Report, whichever is sooner, unless we agree otherwise (the "Disclosure Period"). Send us the text you plan to publish at least 5 Business Days in advance, without secrets or personal data. We may publish our own advisory.

11. Safe harbour

11.1 If you make a good-faith effort to follow this Policy, we will: (a) treat your research as authorised: as the person entitled to control access to the Service, we consent to access that complies with this Policy (Computer Crimes Act 1997 ss.2(5), 3 and 5); (b) waive the testing restrictions in Terms clause 14.1(i) and AUP clause 12 to the extent that research needs; (c) not bring or support any civil claim, or complain to the police or any authority, about it; and (d) if a third party acts against you over that research, make known that it was authorised.

11.2 Limits. We can authorise access only to systems we control. We cannot authorise access to the Platforms, our payment processor, our other service providers or Customer Personal Data controlled by Customers, and cannot bind the Public Prosecutor, the Personal Data Protection Commissioner, the police or other third parties. Conduct breaking clause 8 or the law, such as unlawfully collecting or disclosing personal data (PDPA s.130), is not protected.

11.3 If your research reveals a Personal Data Breach, we may have to notify under clause 6.2, but will not name you without your consent unless the law requires it.

11.4 Unsure whether something is allowed? Ask [email protected] before testing.

12. Recognition

12.1 No bounty. We do not pay bounties. Any token of thanks is a discretionary gift creating no obligation or employment.

12.2 Credit. With your consent, we may credit you by your chosen name or handle on our website or in our advisory for the first valid Report of an in-scope Vulnerability we fix. Credit is optional, and you may ask us to remove it at any time.

13. Your personal data

13.1 We use your contact details and Report to handle it, contact you, credit you if you agree and keep records. They are "Support and Request Data" under our Privacy Policy (section 3, category H), kept for 3 years after the matter closes (section 10). Pseudonymous Reports are welcome. If you live outside Malaysia, you also keep the rights your local law gives you over this data, and you may contact us at [email protected] to use them.

14. security.txt

14.1 We publish a security contact file at /.well-known/security.txt on our website, served over HTTPS in the standard format (RFC 9116). It names [email protected] as our security contact, links to this Policy, and lists English and Bahasa Malaysia as our preferred languages.

14.2 The file states an expiry date no more than 12 months ahead, and we renew it before that date.

15. Changes and contact

15.1 We may update this Policy when our practices change; the version and date above show the current text. Research under way follows the version in force when it began.

15.2 Contact: [email protected] for security reports (subject "Security"), our Data Protection Officer and legal notices. Post: Malaysia.

Change log