Vulnerability Disclosure

Last updated: January 15, 2026

Vulnerability Disclosure Policy

Document owner: Chief Information Security Officer Version: 3.0 Effective date: January 1, 2026 Last updated: January 15, 2026 Classification: Public — Trust Center Review cadence: Annual, and upon material security program changes Company: Acme Cloud, Inc. Address: 1200 Market Street, Suite 400, San Francisco, CA 94103, USA Primary contacts: trust@acmecloud.com | security@acmecloud.com | privacy@acmecloud.com

1. Document Purpose and Executive Summary

This Vulnerability Disclosure Policy ("Policy") establishes Acme Cloud, Inc.'s ("Company," "we," "us," or "our") formal framework for receiving, processing, triaging, remediating, and disclosing security vulnerabilities discovered in our products, services, and infrastructure. This Policy demonstrates our commitment to transparency, responsible security research, and collaborative engagement with the global security research community.

The vulnerability disclosure program is a critical component of our defense-in-depth security strategy, complementing automated security scanning, penetration testing, code reviews, and continuous security monitoring. By establishing clear guidelines for external security researchers, we create a structured channel for identifying and addressing security weaknesses before they can be exploited by malicious actors.

This Policy applies to all Acme Cloud assets within the defined scope, establishes safe harbor protections for good-faith security researchers, defines our disclosure coordination process, and outlines our recognition program for contributors to our security posture.

Key Policy Commitments:

We will acknowledge vulnerability reports within two (2) business days
We will provide status updates at minimum every ten (10) business days
We will remediate critical vulnerabilities within seventy-two (72) hours target
We will not pursue legal action against researchers acting in good faith
We will publicly recognize researchers who report valid vulnerabilities (with consent)

2. Definitions

For purposes of this Policy, the following terms shall have the meanings set forth below:

Term	Definition
Vulnerability	A weakness in a system, application, or process that could be exploited to compromise the confidentiality, integrity, or availability of information or systems. This includes software bugs, misconfigurations, design flaws, and process deficiencies.
Security Researcher	Any individual or organization conducting security testing activities to identify vulnerabilities in computer systems, networks, or applications, whether independently or under engagement.
Good Faith	Acting with honest intent, without malicious purpose, and in compliance with applicable law and this Policy. Good faith requires avoiding unnecessary harm, respecting privacy, and promptly reporting discovered vulnerabilities.
Safe Harbor	Legal protection extended by the Company to security researchers who comply with this Policy, shielding them from legal action related to authorized security research activities.
Coordinated Disclosure	A process whereby the discoverer of a vulnerability shares information with the affected vendor under embargo, allowing time for remediation before public disclosure.
CVSS	Common Vulnerability Scoring System, an industry-standard framework for assessing the severity of security vulnerabilities based on exploitability, scope, and impact metrics.
CVE	Common Vulnerabilities and Exposures, a publicly disclosed cybersecurity vulnerability identifier maintained by MITRE Corporation.
Proof of Concept (PoC)	A demonstration that a vulnerability is exploitable, typically through code, screenshots, or documentation showing the attack path and impact.
Triage	The process of evaluating a reported vulnerability to assess its validity, severity, scope, and appropriate remediation priority.
Remediation	Actions taken to fix, patch, mitigate, or otherwise address a vulnerability to eliminate or reduce associated risk.
Bug Bounty	A reward program offering monetary compensation to researchers who report valid security vulnerabilities (not currently offered by Acme Cloud).
Embargo Period	The time between initial vulnerability report and public disclosure, during which the vendor works to remediate the issue.
Subprocessor	A third-party service provider that processes data on behalf of Acme Cloud in connection with service delivery.
Zero-Day	A previously unknown vulnerability with no available patch at the time of discovery or exploitation.
Attack Surface	The sum of all points where an unauthorized user could attempt to enter data to or extract data from the Company's systems.

3. Scope of Testing Authorization

3.1 In-Scope Assets

The following assets are authorized for security testing under this Policy:

Asset Category	Specific Assets	Authorization Level	Notes
Production Web Applications	acmecloud.com, *.acmecloud.com (excluding customer subdomains)	Full testing authorized	Rate limiting applies
Customer-Facing SaaS Platform	app.acmecloud.com, api.acmecloud.com	Full testing on researcher-owned accounts	Do not test against other customers
Authentication Systems	auth.acmecloud.com, login.acmecloud.com	Limited testing authorized	No credential stuffing or account enumeration
Public API Endpoints	api.acmecloud.com/v1/, api.acmecloud.com/v2/	Testing authorized per API documentation	Respect rate limits; use test credentials
Mobile Applications	Official iOS and Android applications from App Store/Google Play	Full testing authorized	Test against latest released version
Browser Extensions	Official Chrome and Firefox extensions	Full testing authorized	Test against latest released version
Open Source Repositories	github.com/acmecloud/*	Full testing authorized	Follow responsible disclosure for libraries
Documentation Sites	docs.acmecloud.com, developers.acmecloud.com	Limited testing authorized	Content injection vulnerabilities in scope
Status Page	status.acmecloud.com	Limited testing authorized	Availability testing not authorized

3.2 Out-of-Scope Assets and Activities

The following are explicitly out of scope and testing is not authorized:

Category	Examples	Rationale	Alternative Action
Third-Party Services	CDN providers, analytics platforms, payment processors	Not under Company control	Report directly to service provider
Customer Data and Accounts	Any customer tenant, customer-configured integrations	Privacy and legal concerns	Use only researcher-owned test accounts
Social Engineering	Phishing employees, pretexting, tailgating	Employee safety and privacy	Not permitted under any circumstances
Physical Security	Office access, hardware tampering, dumpster diving	Physical safety concerns	Requires separate written authorization
Denial of Service	Resource exhaustion, traffic flooding, crash testing	Service availability impact	Report theoretical DoS vulnerabilities without testing
Spam and Mass Messaging	Email flooding, notification abuse	User experience impact	Report vulnerability without exploitation
Data Destruction	Deleting data, corrupting databases	Irreversible harm	Demonstrate read-only proof of concept
Privacy Violations	Accessing personal data, surveillance	Legal and ethical concerns	Report vulnerability without accessing PII
Competitor Systems	Partner integrations, marketplace apps	Not under Company control	Report to respective vendors
Automated Scanning (Aggressive)	High-volume automated tools, fuzzing without coordination	Service degradation risk	Coordinate with security team before automated testing
Employee Personal Accounts	Social media, personal email, personal devices	Privacy violations	Not permitted under any circumstances
Acquired Companies Pre-Integration	Systems of recently acquired companies not yet integrated	Scope uncertainty	Contact security team for clarification

3.3 Testing Conduct Requirements

Researchers must adhere to the following conduct requirements during testing:

Requirement	Specification	Verification Method
Rate Limiting	Maximum 10 requests per second for automated testing	Monitored via WAF logs
Session Management	Use only researcher-controlled test accounts	Account verification during triage
Data Access	Access minimum data necessary to demonstrate vulnerability	Report review
Data Retention	Delete any inadvertently accessed data promptly	Self-attestation in report
Confidentiality	Do not disclose vulnerability until coordinated disclosure	Public monitoring
Communication	Use designated channels only (security@acmecloud.com)	Channel verification
Professional Conduct	No threats, extortion, or unprofessional communication	Communication review
Tool Usage	Avoid tools that may cause service degradation	Activity monitoring
Geographic Restrictions	Comply with applicable sanctions and export controls	IP verification
Legal Compliance	Comply with all applicable laws beyond this Policy	Self-attestation

4. Safe Harbor Provisions

4.1 Legal Protection Commitment

Acme Cloud extends the following legal protections to security researchers who comply with this Policy:

4.1.1 Authorization Under Computer Fraud and Abuse Act (CFAA)

We consider security research conducted in accordance with this Policy to be authorized access under the Computer Fraud and Abuse Act (18 U.S.C. § 1030), to the extent such authorization is legally effective. We will not pursue civil claims or initiate criminal complaints against researchers who:

Conduct testing only against in-scope assets
Avoid privacy violations, data destruction, and service disruption
Report vulnerabilities promptly through designated channels
Do not exploit vulnerabilities beyond proof-of-concept demonstration
Do not access, modify, or exfiltrate customer data
Maintain confidentiality until coordinated disclosure

4.1.2 Safe Harbor Limitations

Safe harbor protection does not extend to:

Excluded Activity	Rationale	Consequence
Violations of laws unrelated to security research	Legal compliance requirement	May result in law enforcement referral
Access to customer data without authorization	Privacy and legal obligations	Not protected; may result in prosecution
Testing against out-of-scope assets	Scope limitation	Not protected under this Policy
Disclosure in violation of embargo	Coordinated disclosure requirement	Recognition forfeited; future reports may be declined
Extortion or ransom demands	Criminal conduct	Not protected; will result in law enforcement referral
Repeated Policy violations after warning	Bad faith indicator	Safe harbor revoked for individual
Testing from sanctioned jurisdictions	Export control compliance	May not be legally protected

4.2 Third-Party Safe Harbor Coordination

If your research involves third-party services integrated with Acme Cloud, we will make good-faith efforts to coordinate with those parties regarding safe harbor protections. However, we cannot guarantee third-party enforcement decisions. Researchers should review third-party vulnerability disclosure policies before testing integrated services.

4.3 Employment and Contractor Exclusions

Current employees, contractors, and their immediate family members are not eligible for public recognition under this Policy. Such individuals should report security concerns through internal channels (internal security ticketing system, direct CISO contact, or whistleblower hotline per Whistleblower Policy).

5. Vulnerability Reporting Procedures

5.1 Reporting Channels

Channel	Contact Information	Availability	Encryption	Use Case
Primary Email	security@acmecloud.com	24/7 (monitored business hours)	PGP available	All vulnerability reports
Encrypted Submissions	security.txt PGP key	24/7	Required for sensitive data	Reports containing exploit code or sensitive details
Web Form	acmecloud.com/security/report	24/7	TLS only	Structured report submission
HackerOne (Monitoring)	hackerone.com/acmecloud	N/A	Platform native	We monitor for reports; not primary channel
Emergency Line	+1-415-555-0199	24/7	No	Critical vulnerabilities requiring immediate attention

5.2 Report Content Requirements

Complete vulnerability reports should include the following information:

Required Element	Description	Example
Vulnerability Type	Classification of the vulnerability (XSS, SQLi, IDOR, etc.)	"Stored Cross-Site Scripting (XSS)"
Affected Asset	Specific URL, endpoint, application, or component	"https://app.acmecloud.com/dashboard/settings"
Affected Versions	Application version, API version, or date observed	"API v2.3.1, observed January 15, 2026"
Reproduction Steps	Detailed, numbered steps to reproduce the vulnerability	"1. Log in as standard user\n2. Navigate to settings\n3. Enter payload in name field"
Proof of Concept	Code, screenshots, video, or HTTP requests demonstrating the issue	HTTP request/response, screenshot with redactions
Impact Assessment	Your assessment of potential impact to confidentiality, integrity, or availability	"Allows session hijacking of logged-in users"
Severity Estimate	Your CVSS score estimate if possible	"CVSS 3.1 Base Score: 8.1 (High)"
Discovery Context	How you discovered the vulnerability	"Manual testing during API integration review"
Recommended Fix	If known, suggest remediation approach	"Implement output encoding for user-supplied content"
Contact Information	Email or secure contact method for follow-up	"researcher@example.com, Signal: +1-xxx-xxx-xxxx"
Recognition Preference	Whether you wish to be publicly credited	"Yes, credit as 'Jane Doe'"

5.3 Optional but Helpful Information

Environment details (browser, OS, network configuration)
Traffic captures (sanitized of personal information)
Automated tool output (if applicable)
References to similar vulnerabilities (CVE numbers, prior art)
Proposed timeline for coordinated disclosure

6. Vulnerability Handling Process

6.1 Response Timeline Commitments

Phase	Target Timeline	Maximum Timeline	Escalation Trigger
Acknowledgment	1 business day	2 business days	Auto-escalation if not acknowledged
Initial Triage	3 business days	5 business days	Manager escalation at day 4
Severity Assignment	5 business days	7 business days	CISO notification for High/Critical
Remediation Plan	7 business days	14 business days	Executive escalation for Critical
Status Update Cadence	Every 7 days	Every 10 business days	Reporter may request escalation
Critical Remediation	24 hours	72 hours	Incident commander activation
High Remediation	7 days	14 days	Management review
Medium Remediation	30 days	60 days	Standard tracking
Low Remediation	60 days	90 days	Backlog prioritization
Reporter Notification (Resolution)	3 business days after fix	5 business days	Automatic on ticket closure

6.2 Triage and Severity Classification

We use CVSS v3.1 as the baseline for severity classification, adjusted for business context and exploitability:

Severity	CVSS Range	Definition	Remediation SLA	Examples
Critical	9.0 – 10.0	Vulnerabilities allowing unauthenticated remote code execution, mass data exfiltration, or complete system compromise	72 hours	Unauthenticated RCE, SQL injection with full database access, authentication bypass to admin
High	7.0 – 8.9	Vulnerabilities allowing significant impact with some constraints (authentication, user interaction, or limited scope)	14 days	Authenticated privilege escalation, stored XSS in admin panel, SSRF with internal network access
Medium	4.0 – 6.9	Vulnerabilities with moderate impact requiring specific conditions or limited exploitability	60 days	CSRF on non-critical actions, reflected XSS requiring social engineering, information disclosure of non-sensitive data
Low	0.1 – 3.9	Vulnerabilities with minimal impact or requiring unlikely conditions	90 days	Missing security headers, verbose error messages, clickjacking on non-sensitive pages
Informational	0.0	Observations that may indicate security improvements but do not represent exploitable vulnerabilities	No SLA	Best practice recommendations, defense-in-depth suggestions

6.3 Internal Escalation Matrix

Severity	Immediate Notification	Executive Briefing	Board Notification
Critical	CISO (4 hours), VP Engineering	CEO (24 hours)	Audit Committee (if customer data affected)
High	Security Engineering Manager	CISO (weekly summary)	N/A
Medium	Security Engineer on-call	Monthly metrics	N/A
Low	Standard ticket workflow	Quarterly summary	N/A

7. Coordinated Disclosure Framework

7.1 Disclosure Timeline

Acme Cloud requests a standard ninety (90) day embargo period from report acknowledgment to public disclosure. This timeline allows for:

Thorough investigation and root cause analysis
Development and testing of remediation
Deployment to production environments
Customer notification where appropriate
Coordination with affected third parties

7.2 Timeline Modifications

Scenario	Adjustment	Approval Required
Simple fix, low risk	May reduce to 30-60 days	Mutual agreement
Complex remediation	May extend to 120 days	Researcher agreement, written explanation
Active exploitation observed	Accelerated disclosure (7-14 days)	CISO approval
Third-party dependencies	Extension based on vendor timeline	Documented coordination
Researcher request for extension	Considered on case-by-case basis	CISO approval
Holiday or resource constraints	Up to 30 additional days	Mutual agreement

7.3 Disclosure Publication Process

Upon remediation and embargo completion:

Step	Action	Timeline	Responsible Party
1	Verify fix deployed to all production environments	Before disclosure	Engineering
2	Notify researcher of resolution and disclosure readiness	5 days before disclosure	Security Team
3	Prepare security advisory (internal review)	3 days before disclosure	Security Team + Legal
4	Request CVE identifier (if applicable)	5 days before disclosure	Security Team
5	Publish advisory to acmecloud.com/security/advisories	Disclosure date	Security Team
6	Update Hall of Fame (if researcher consents)	Within 5 days of disclosure	Security Team
7	Notify affected customers (if applicable)	Per customer notification SLA	Customer Success

8. Recognition Program

8.1 Security Hall of Fame

Acme Cloud maintains a Security Hall of Fame at acmecloud.com/security/hall-of-fame to recognize researchers who report valid in-scope vulnerabilities.

Recognition Element	Options	Timing
Name/Handle	Real name, pseudonym, or "Anonymous"	At disclosure
Affiliation	Company or independent researcher	At disclosure
Vulnerability Category	General category (XSS, SQLi, etc.)	At disclosure
Recognition Date	Month and year of acknowledgment	At disclosure
Social Link	Twitter/X, LinkedIn, or personal website (optional)	At disclosure

8.2 Recognition Eligibility Criteria

Requirement	Description
Valid in-scope vulnerability	Confirmed security issue within Policy scope
Policy compliance	Researcher followed all Policy requirements
First reporter	First to report unique vulnerability (see duplicate policy)
Not employee or contractor	Current Acme Cloud personnel ineligible
No extortion attempts	No demands for payment as condition of report
Consent to recognition	Researcher affirmatively requests recognition

8.3 Swag and Appreciation

While Acme Cloud does not currently operate a paid bug bounty program, we provide appreciation tokens to recognized researchers:

Item	Eligibility	Notes
Acme Cloud security t-shirt	All recognized researchers	Shipped within 30 days of recognition
Security sticker pack	All recognized researchers	Included with t-shirt shipment
Handwritten thank-you note	Critical/High findings	From CISO
Reference letter	Exceptional contributions	Upon request
LinkedIn recommendation	Outstanding researchers	Upon request

8.4 Bug Bounty Program Evaluation

Acme Cloud evaluates transition to a paid bug bounty program annually based on:

Factor	Current Status	Target for Bounty Consideration
Annual report volume	47 reports (FY2025)	100+ reports
Remediation capacity	12 valid findings remediated	Sustained capacity for 50+ annually
Program maturity	2 years operating	3+ years established
Budget allocation	Not currently budgeted	Executive approval required
Platform evaluation	HackerOne, Bugcrowd, Intigriti assessed	Platform selection complete

9. Duplicate and Invalid Report Handling

9.1 Duplicate Reports

Scenario	Outcome	Recognition
Vulnerability previously reported by external researcher	First reporter receives recognition	Subsequent reporters notified, no recognition
Vulnerability discovered by internal team	External reporter still eligible for recognition	Recognition notes parallel discovery
Vulnerability reported via multiple channels simultaneously	First received report takes precedence	Timestamp comparison
Vulnerability known but not yet remediated	Reporter notified of status	May receive recognition if not previously credited

9.2 Invalid Report Categories

Category	Examples	Response
Out of scope	Third-party services, customer integrations	Redirect to appropriate vendor
Not a vulnerability	Feature request, usability issue	Redirect to product feedback
Theoretical without PoC	"I think there might be XSS" without demonstration	Request proof of concept
Already public	CVE already published, vulnerability in dependency with known patch	Thank and close
Scanner noise	Automated tool false positives	Close with explanation
Policy violations	Tested customer accounts, caused service disruption	Warning or safe harbor revocation

10. Security Advisory Publication

10.1 Advisory Content

Security advisories published at acmecloud.com/security/advisories include:

Element	Description	Inclusion Criteria
Advisory identifier	Unique ACME-YYYY-NNN format	All advisories
CVE identifier	Where assigned by MITRE or CNA	Critical and High severity
Title	Brief description of vulnerability	All advisories
Severity	CVSS score and qualitative rating	All advisories
Affected versions	Specific versions or date ranges	All advisories
Description	Technical details appropriate for defenders	All advisories
Impact	Potential consequences of exploitation	All advisories
Remediation	Actions customers should take	All advisories
Workarounds	Temporary mitigations if available	Where applicable
Timeline	Discovery, report, fix, disclosure dates	All advisories
Credit	Researcher acknowledgment (with consent)	Where researcher consents
References	Related CVEs, vendor advisories	Where applicable

10.2 Advisory Distribution

Channel	Audience	Timing
Security advisories page	Public	At disclosure
RSS feed	Subscribers	At disclosure
Email notification	Enterprise customers (Critical/High)	24-48 hours before public disclosure
In-app notification	Affected customers	At disclosure
Status page	All users (if service impact)	As appropriate

11. Metrics and Program Transparency

11.1 FY2025 Program Metrics

Metric	Value	Trend
Total reports received	47	+23% YoY
Valid vulnerabilities confirmed	12	+20% YoY
Critical severity	1	Stable
High severity	2	-1 YoY
Medium severity	6	+2 YoY
Low severity	3	Stable
Average acknowledgment time	1.2 business days	Improved from 1.8 days
Average time to remediate (Critical)	58 hours	Within SLA
Average time to remediate (High)	9 days	Within SLA
Average time to remediate (Medium)	34 days	Within SLA
Researchers recognized in Hall of Fame	8	+3 YoY
Reports rejected (out of scope/invalid)	35	Expected ratio
Safe harbor invocations	0	No disputes

11.2 Continuous Improvement Initiatives

Initiative	Status	Target Completion
Implement structured intake form	Completed Q4 2025	Done
Automate acknowledgment emails	Completed Q3 2025	Done
Integrate with GRC vulnerability tracker	Completed Q2 2025	Done
Launch test account provisioning program	Planned Q2 2026	In progress
Evaluate bug bounty platform	Planned Q4 2026	Not started
Publish metrics dashboard	Planned Q3 2026	Not started

12. SOC 2 and ISO 27001 Control Mapping

12.1 SOC 2 Trust Services Criteria Mapping

Control ID	Control Description	Policy Implementation
CC1.1	COSO Principle 1: Demonstrates commitment to integrity and ethical values	Safe harbor provisions, ethical treatment of researchers
CC2.2	Internal and external communication	Defined reporting channels, response timelines
CC3.1	Risk identification	Vulnerability intake and triage process
CC3.2	Risk assessment	CVSS-based severity classification
CC3.3	Risk management	Remediation SLAs and escalation procedures
CC4.1	Monitoring controls	Vulnerability metrics, program effectiveness review
CC4.2	Deficiency evaluation and remediation	Vulnerability remediation tracking
CC5.1	Control selection and development	Vulnerability disclosure program as preventive control
CC6.1	Logical and physical access controls	Scope limitations, authorized testing requirements
CC6.8	Vulnerability management	Core purpose of this Policy
CC7.1	Detection of security events	External researcher reports as detection mechanism
CC7.2	Incident response monitoring	Integration with incident response plan
CC7.3	Incident response procedures	Escalation matrix, remediation SLAs
CC7.4	Incident response communication	Reporter notification, advisory publication

12.2 ISO 27001:2022 Annex A Control Mapping

Control	Control Title	Policy Implementation
A.5.7	Threat intelligence	External researcher reports as threat intelligence source
A.5.24	Information security incident management planning	Vulnerability handling process
A.5.25	Assessment and decision on information security events	Triage and severity classification
A.5.26	Response to information security incidents	Remediation process and SLAs
A.5.27	Learning from information security incidents	Metrics tracking, continuous improvement
A.5.28	Collection of evidence	Report documentation requirements
A.6.8	Information security event reporting	Reporting channels and procedures
A.8.8	Management of technical vulnerabilities	Core vulnerability management process
A.8.12	Data leakage prevention	Scope restrictions, researcher conduct requirements
A.8.16	Monitoring activities	Researcher activity monitoring

13. Legal and Regulatory Compliance

13.1 Applicable Legal Frameworks

Framework	Applicability	Policy Alignment
Computer Fraud and Abuse Act (CFAA)	US federal law	Safe harbor provisions align with DOJ good-faith research guidance
California Comprehensive Computer Data Access and Fraud Act	California state law	Safe harbor extends to state law equivalent
EU Directive 2013/40/EU	EU operations	Coordinated disclosure process
UK Computer Misuse Act 1990	UK operations	Good-faith research protections
GDPR Article 32	EU data subjects	Vulnerability management as security measure
CCPA/CPRA	California residents	Security program component
NIST Cybersecurity Framework	Voluntary adoption	Aligned with Identify, Protect, Detect functions
DOJ Cybersecurity Unit Guidance	US federal guidance	Safe harbor language aligned with 2022 guidance

13.2 Export Control Considerations

Researchers must comply with US export control regulations (EAR, OFAC sanctions). Acme Cloud cannot provide safe harbor protections for research conducted from comprehensively sanctioned jurisdictions or by individuals on restricted party lists. Researchers are responsible for their own export control compliance.

14. Program Governance and Oversight

14.1 Roles and Responsibilities

Role	Responsibilities	Escalation Authority
CISO	Policy ownership, program oversight, Critical/High approval	Executive team, Board
Security Engineering Manager	Day-to-day operations, triage oversight	CISO
Security Engineer (On-Call)	Initial triage, researcher communication	Security Engineering Manager
Engineering Team Leads	Vulnerability remediation implementation	VP Engineering
Legal Counsel	Safe harbor review, regulatory compliance	General Counsel
Communications	Advisory publication, external communications	VP Marketing
Customer Success	Customer notification for affecting vulnerabilities	VP Customer Success

14.2 Policy Review and Updates

Review Type	Frequency	Trigger	Approver
Scheduled review	Annual	Calendar	CISO
Material change review	As needed	Program changes, regulations	CISO + Legal
Post-incident review	After significant findings	Critical vulnerability, process failure	CISO
Metrics review	Quarterly	Standard reporting	Security Engineering Manager
Benchmark review	Annual	Industry comparison	CISO

15. Test Account Provisioning

15.1 Researcher Account Program

Qualified security researchers may request dedicated test accounts to facilitate in-scope testing:

Account Type	Provisioning Time	Eligibility	Limitations
Standard test tenant	3 business days	Validated researchers with research scope	30-day validity, renewable
API test credentials	2 business days	Validated researchers	Rate-limited, test environment
Enterprise feature access	5 business days	Researchers testing enterprise features	Requires scope approval

15.2 Account Request Process

Email security@acmecloud.com with subject "Test Account Request"
Include: researcher identity verification, research scope description, expected testing duration
Security team validates request and provisions account
Account credentials delivered via secure channel (PGP or Signal)
Researcher acknowledges Policy compliance
Account deprovisioned automatically at expiration or upon request

16. Relationship to Other Security Programs

16.1 Program Integration

Program	Relationship	Cross-Reference
Penetration Testing	Complement community disclosure with annual professional testing	Penetration Testing Program
Incident Response	Critical vulnerabilities trigger incident response procedures	Incident Response Plan
Third-Party Risk	Vulnerabilities in vendor systems coordinated through TPRM	Third-Party Risk Management
Security Overview	Vulnerability management as component of security program	Security Overview
Change Management	Remediation changes follow standard change management	Internal change management policy

16.2 Vulnerability Source Integration

All vulnerability sources feed unified tracking:

Source	Integration Point	Deduplication
External researcher reports	This Policy	Manual triage
Penetration test findings	Pen test program	Automated matching
Automated scanning (SAST/DAST)	CI/CD pipeline	Automated deduplication
Dependency scanning (SCA)	Build process	Automated deduplication
Bug bounty platform monitoring	Monitoring dashboard	Manual review
Customer reports	Support ticketing	Manual triage
Internal security testing	Security team testing	Manual matching

Document revision history

Version	Date	Author	Summary of changes
1.0	2024-06-01	Legal & Compliance	Initial Trust Center publication
2.0	2025-03-15	GRC Program	SOC 2 Type II alignment refresh; expanded subprocessors
2.5	2025-09-01	Security Engineering	Encryption standards update; ISO 27001 mapping
3.0	2026-01-15	Trust Center Program	Full procurement-grade expansion; 34-document set

Contact

Acme Cloud, Inc. 1200 Market Street, Suite 400 San Francisco, CA 94103, USA

Channel	Email	Use case
Trust & procurement	trust@acmecloud.com	Security questionnaires, trust reviews
Security	security@acmecloud.com	Incidents, vulnerabilities, control questions
Privacy	privacy@acmecloud.com	DSRs, privacy assessments
Legal	legal@acmecloud.com	Contractual, DPA, legal notices

17. Security.txt and Contact Information

Acme Cloud publishes machine-readable security contact information at:

security.txt Location: https://acmecloud.com/.well-known/security.txt

Field	Value
Contact	mailto:security@acmecloud.com
Encryption	PGP key URL
Acknowledgments	https://acmecloud.com/security/hall-of-fame
Policy	https://acmecloud.com/trust-center/vulnerability-disclosure
Preferred-Languages	en
Canonical	https://acmecloud.com/.well-known/security.txt
Expires	Updated annually

PGP Key Fingerprint: Available at security.txt, rotated annually with 30-day overlap period.

18. Acknowledgments

Acme Cloud thanks the global security research community for their contributions to our security posture. Your responsible disclosure helps protect our customers and the broader ecosystem. We are committed to treating all good-faith researchers with respect, transparency, and appreciation.

Report vulnerabilities: security@acmecloud.com
Trust inquiries: trust@acmecloud.com
PGP encryption: Available via security.txt
Hall of Fame: acmecloud.com/security/hall-of-fame

This Policy is not a contract and may be updated at any time. The "Last updated" date indicates the current version. Material changes will be communicated via security.txt and Trust Center notification.