Security and Vulnerability Reporting.

1. Our Commitment.

RegLeg builds regulatory intelligence software that partners and their customers rely on to manage real compliance obligations. We take that responsibility seriously. We welcome good faith reports from independent researchers, academic teams, partner security staff, and customers who find a weakness in our products or infrastructure. If you report a vulnerability under this policy, RegLeg commits to acknowledge receipt promptly, work with you in good faith to understand and validate the issue, remediate confirmed vulnerabilities on a risk based timeline, and credit you publicly when you want that credit and the remediation permits disclosure.

2. Scope.

This policy covers vulnerabilities you discover in the systems listed below. RegLeg may expand this list from time to time and will update the list on this page.

3. Out of Scope.

The following are not eligible for recognition under this program and in some cases may constitute a violation of the rules of engagement. Please do not submit reports about these items unless you have combined them into a meaningful, exploitable finding.

1. Findings from automated scanners without a demonstrated exploit path
2. Missing best practice headers (for example, Content Security Policy, X-Frame-Options, HTTP Strict Transport Security, referrer policy) without a demonstrated exploit
3. Self cross-site scripting that requires the victim to paste code into their own console
4. Clickjacking on pages without sensitive state changing actions
5. Cross-site request forgery on forms without a sensitive, authenticated state change
6. Rate limiting, brute force, or account lockout issues on noncritical endpoints
7. Social engineering of RegLeg staff, partners, customers, vendors, or end users
8. Physical attacks on RegLeg property or employees
9. Denial of service, distributed denial of service, and volumetric or resource exhaustion attacks
10. Reports about software versions reported by banner without a working exploit
11. Issues in third party services or libraries that RegLeg has not deployed, modified, or misconfigured
12. Open ports that do not expose a vulnerable service
13. Username enumeration on public login pages, password reset pages, and registration pages where the behavior is by design
14. Reports about email configuration such as SPF, DKIM, or DMARC without a demonstrable spoofing impact
15. Reports about cookie attributes on cookies that do not carry authentication or sensitive state

4. Rules of Engagement.

We ask that all researchers abide by the following rules. Testing that stays within these rules is covered by the safe harbor in Section 9.

1. Only test against accounts and tenants that you own or that you are separately authorized to access. Do not test using another customer’s data or another customer’s tenant.
2. Do not attempt to access, modify, exfiltrate, or destroy data that does not belong to you. If you inadvertently access such data, stop testing immediately, avoid viewing the data, retain no copies, and include that fact in your report.
3. Do not run automated scans that generate significant volume against production systems. Rate limit your testing and use targeted, manual techniques wherever possible.
4. Do not use denial of service, distributed denial of service, traffic flooding, or resource exhaustion techniques.
5. Do not use social engineering, phishing, pretexting, or physical intrusion against RegLeg, our partners, our customers, our vendors, or our personnel.
6. Do not install malware, ransomware, backdoors, persistent implants, or cryptocurrency miners.
7. Do not pivot from a confirmed vulnerability to explore systems beyond the minimum needed to demonstrate impact.
8. Do not publicly disclose a vulnerability before RegLeg has had a reasonable opportunity to investigate and remediate. See Section 8 for the coordinated disclosure timeline.
9. Do not demand payment, bug bounty, or other consideration as a condition of reporting or withholding a vulnerability. RegLeg does not negotiate against extortion.
10. Comply with all applicable laws. Nothing in this policy authorizes activity that is otherwise illegal.

5. How to Report.

Send all suspected security vulnerabilities to the address below. We prefer encrypted email for anything that includes sensitive proof of concept material. Please do not submit vulnerability reports through public social media, support chat, or the general contact form, as those channels do not route to the security team and may be seen by others.

6. What to Include in a Report.

A good report helps us validate and reproduce the issue quickly. Please include the following, to the extent known:

1. A clear title and a plain language summary of the issue and its impact
2. The affected product, domain, or endpoint, with the full URL and the date and time of testing
3. The account, tenant, or role under which you were testing
4. Step by step instructions to reproduce the finding, including any required payloads, headers, or tooling
5. Screenshots, screen recordings, request and response captures, or minimal proof of concept code
6. Your assessment of severity and the reasoning behind it, ideally mapped to CVSS 3.1 or CVSS 4.0
7. Whether the vulnerability is already public, embargoed elsewhere, or known to you alone
8. How you want to be credited if the finding is confirmed, or that you prefer to remain anonymous

7. Triage and Response Times.

RegLeg triages reports on a risk based schedule. The targets below are service level objectives, not contractual guarantees, and RegLeg may deviate when complexity, vendor coordination, or customer impact require it. Severity is assessed using CVSS, the characteristics of our platform, and the realistic exploitability of the finding. RegLeg reserves the right to reclassify severity after investigation.

RegLeg will keep the reporter reasonably informed about the status of an accepted finding until it is closed. If RegLeg determines that a report does not describe a valid vulnerability, or falls within an out of scope category, RegLeg will explain that decision to the reporter.

8. Coordinated Disclosure.

RegLeg follows the principles of coordinated vulnerability disclosure published by the US Cybersecurity and Infrastructure Security Agency and endorsed by the International Organization for Standardization in ISO/IEC 29147. RegLeg asks that researchers not publicly disclose a vulnerability, including any technical details, proof of concept code, screenshots, or customer data, until RegLeg has had a reasonable opportunity to remediate and, where appropriate, notify affected partners and customers.

The default coordination window is ninety days from RegLeg’s confirmation that a vulnerability is valid. RegLeg will work with the reporter to adjust that window up or down based on severity, complexity of remediation, partner coordination, and active exploitation. RegLeg will not threaten legal action against a researcher who has acted in good faith under this policy, including where that researcher ultimately publishes under a reasonable coordinated timeline.

9. Safe Harbor.

RegLeg considers security research and vulnerability disclosure activities conducted consistent with this policy to be authorized conduct and to be conducted in good faith. Subject to the conditions below, RegLeg will:

1. Not initiate or support legal action against the researcher for activity that is performed in good faith, within the rules of engagement in Section 4, and within the scope defined in Section 2
2. Work with the researcher to understand and address the issue quickly
3. Waive any claim under the Computer Fraud and Abuse Act, the Digital Millennium Copyright Act, similar state and foreign laws, and our own terms of use to the extent those laws and terms would otherwise prohibit the in scope activity
4. If a third party initiates legal action against the researcher based on conduct performed under this policy and within its rules of engagement, take reasonable steps to make our authorization known

This safe harbor is conditional. It does not apply to activity that violates the rules of engagement in Section 4, that is performed in bad faith or under a pretext of research to obtain other benefits, that targets another customer or its data without that customer’s written authorization, or that otherwise violates applicable law. It does not authorize extortion, and it does not modify or waive any obligations under applicable law that cannot be modified or waived by contract.

If legal authorization is unclear for a particular test, contact security@regleg.com before you begin. RegLeg will do its best to clarify scope and, where appropriate, expand this policy in writing.

10. Recognition.

RegLeg maintains a public acknowledgments page for researchers who have reported valid vulnerabilities to us under this policy and who have chosen to be credited. At this time, RegLeg does not offer monetary bounties as a standing program. RegLeg may provide swag, letters of acknowledgment, or discretionary awards for particularly impactful findings and may adopt a paid bounty program in the future. Researchers should not rely on a particular form of recognition as a condition of reporting.

11. Customer and Partner Security Contacts.

Authorized Partners and their customers should use their established support channels for routine security questions, evidence requests, and documentation, including SOC 2 reports, penetration test summaries, subprocessor lists, and security questionnaire responses. Where a partner or customer has executed an agreement with RegLeg that provides an incident notification process, that process governs and supersedes this public policy. Security incidents affecting a partner tenant will be handled through the notification mechanisms defined in the applicable Partner Agreement, including in app and per tenant webhook notifications consistent with the RegLeg zero retention personal data architecture.

12. Platform Security Overview.

RegLeg designs the platform around a small set of durable security principles. This overview is intended as context for researchers and for customer security teams conducting diligence, and it is not a representation of any specific compliance attestation. Formal certifications, scope statements, and evidence packages are available under nondisclosure through your Authorized Partner or the RegLeg trust center.

Tenant isolation

Partner and customer data is logically segregated at the tenant layer. Cross tenant access is not a feature.

Identity and access

Production access is restricted to a small number of named personnel using multifactor authentication, least privilege roles, and just in time elevation for break glass operations.

Encryption

Data in transit is protected using current industry standard transport layer security configurations. Data at rest is encrypted using current industry standard algorithms.

Zero retention personal data architecture

End users of the platform are represented within RegLeg systems by opaque identifiers, not by personally identifiable account attributes. Partner administrator records that include personally identifiable information are held in an external vault under a written subprocessor arrangement with each Authorized Partner. See the Privacy Policy and Trust & Architecture page for details.

Secure development

RegLeg uses peer code review, dependency scanning, static analysis, and periodic third party penetration testing in its software development lifecycle. High and critical findings are tracked to remediation.

Monitoring and response

RegLeg operates centralized logging and monitoring for security relevant events and maintains a written incident response plan that is exercised at least annually.

13. Security Incident Notification.

This policy governs the reporting of suspected vulnerabilities. It does not, by itself, create a contractual obligation on RegLeg to notify any particular party of a security incident. RegLeg’s incident notification obligations are defined in the applicable Partner Agreement, Data Processing Addendum, or other written contract with the relevant Authorized Partner or customer, as well as by applicable law. In the event of a suspected security incident affecting the platform, RegLeg will follow the notification process defined in those contracts and will coordinate with the affected Authorized Partners.

14. Changes to This Policy.

RegLeg may update this policy from time to time. When we make material changes, we will update the “Last updated” date at the top of this page and, where appropriate, provide additional notice. The current version is always available at this URL.

15. Contact.

Security reports: security@regleg.com (PGP encouraged).

All other matters, including general questions about this policy:

RegLeg Solutions, Inc.
Attention: Chief Information Security Officer
30 N Gould Street, Suite #64894
Sheridan, WY 82801
Email: security@regleg.com