Security and Responsible Disclosure Policy

1. How we protect the Platform

• •Access is checked on the server, sign-in is required for the Platform, and each user sees only the workspaces, sides and roles they hold. Administrative functions need the master-administrator role and a fresh verification code.
• •Sign-in needs a password plus an emailed verification code (with an optional 30-day trusted device). There are rate limits and account lockout, one active session per account, a 15-minute access token and automatic sign-out after 30 minutes of inactivity. Invitation links do not sign anyone in.
• •Traffic is encrypted in transit. The database and its backups are encrypted at rest by our hosting provider with provider-managed keys, as the provider has confirmed in writing.
• •Important actions are written to an audit trail. Staff can see workspace content only after the workspace owner approves a read-only support session, which is limited to 2 hours and logged.
• •Before each release we run an automated check that routes require sign-in or are on an approved public list, and we check the service from outside. Parts of the service that the current product does not use are switched off.

We do not hold a SOC 2 or ISO 27001 certificate and do not claim one. Uploaded files are not yet scanned for malware and are labelled accordingly. No system can be guaranteed completely secure.

2. Reporting a vulnerability

• •Email support@kpiandsla.com with the subject “Security”. Include what you found, the steps to repeat it and the impact. Please do not include real customer data.
• •We aim to acknowledge within 3 working days, give an initial assessment within 10 working days and keep you updated until it is fixed.
• •We do not intend to take legal action against good-faith research that follows the rules below.

3. Rules for researchers

• •Test only with accounts you own. Do not access, change or delete another person’s data; stop and tell us if you reach any.
• •No denial-of-service, spam, social engineering of our staff or customers, or physical attacks.
• •Give us a reasonable time to fix the issue before you tell anyone else.

We do not currently offer a paid reward. We are glad to thank researchers publicly if they wish.

4. If something goes wrong

We contain the issue, assess what data was affected, tell affected customers without undue delay and within the period the law requires, tell authorities where the law requires (including CERT-In within 6 hours where its directions apply), fix the cause, and keep a short summary of what happened and what changed.