1. Independence and required cadence
- Engage a qualified security testing provider independent of the personnel who designed and implemented the assessed application. Record the provider, assessor qualifications, independence, accountable OpenTeam owner, and written agreement.
- Require a third-party penetration test at least annually. After material changes to authentication, isolation, external APIs, or sensitive-data processing, document whether an additional assessment is needed before release and obtain the security owner's decision.
- Track the last completed assessment and the next due date only after completion is verified. An internal review, automated vulnerability scan, vendor security badge, or another platform's app review does not substitute for this independent engagement.
2. Scope and rules of engagement
- Agree in writing on target hosts and versions, web and API coverage, authenticated roles, Team/account isolation, OAuth and token handling, agent/runtime boundaries where applicable, and all exclusions.
- Define the testing window, contacts, permitted techniques, request limits, stop conditions, incident escalation, evidence handling, and restoration/cleanup responsibilities before testing begins.
- Use an isolated environment and synthetic data where possible. Production testing requires explicit written approval. Third-party platforms and customer infrastructure remain outside scope unless their owners also authorize testing.
- Exclude denial-of-service, destructive activity, and social engineering unless separately approved in the rules of engagement. Protect secrets and customer data encountered during testing.
3. Assessment and report requirements
- Require risk-based manual testing supported by appropriate automated tools. Evaluate applicable OWASP web/API risks, access-control and business-logic abuse, authentication, session handling, sensitive-data exposure, and configuration weaknesses.
- Obtain a dated report identifying the independent provider, scope, tested versions, methodology, coverage and exclusions, executive summary, findings and severity rationale, reproduction evidence, and remediation recommendations.
- A point-in-time report supports only its stated scope and dates. Do not turn a limited assessment or the absence of identified issues into a guarantee that the platform is vulnerability-free.
4. Remediation, independent retest, and retention
- Assign finding owners, prioritize containment and remediation by risk, and apply the SSDLC release gates for critical and high-severity findings.
- Obtain provider retesting of critical and high findings and retain the retest report or signed closure statement. Record remaining findings, compensating controls, and time-limited approvals; a fix without retesting is not verified closure.
- Keep the agreement, authorization, final report, remediation tracker, retest results, reviewer decision, and next assessment due date access-controlled for at least 12 months, or longer where required.
- Share reports or redacted summaries only after an access and confidentiality review. Public statements must accurately describe the provider's completed work and unresolved findings; until evidence is verified, the status remains unverified.
Questions and evidence requests
Contact [email protected] for security policy questions, evidence requests, or corrections to this disclosure. Do not include passwords, access tokens, or sensitive customer data in an initial message.
Related documents: security overview, Privacy Policy, and Terms of Service.