Security & Data Protection

Vulnerability Disclosure Policy

FirmPro, Inc. — DepreciationPro

Last updated: 2026-08-03

1. Introduction

FirmPro, Inc. operates DepreciationPro, a fixed-asset depreciation platform used by CPA firms to prepare and defend client tax returns. We take the security of that data seriously, and we would rather hear about a vulnerability from you than discover it any other way.

Reporting vulnerabilities to us is open to public participation. Participation is not conditioned on your nationality, your age, or any other limiting criterion. The one honest caveat we must state: we may be unable to collaborate with entities subject to certain governmental sanctions.

This policy describes what you may test, what you must not do, what to do in the specific case where you reach data belonging to a firm that is not yours, what protection you have when you act in good faith, and what you can expect from us in return.

2. Official Channels

Report vulnerabilities to [email protected]. This address is monitored for security reports and is deliberately kept separate from our customer-support channels.

Reports may be submitted anonymously. If you share contact information, we will acknowledge receipt of your report within 3 business days.

That construction is deliberate, and it has three consequences worth stating plainly:

• Anonymous reports are accepted and acted on. You do not need to tell us who you are for us to investigate and fix what you found.
• Acknowledgement, status updates, and named credit require contact information. If you send us nothing to reply to, there is nothing for us to reply to.
• Safe harbor, and the cooperative path described in §5 "If you reach another firm's data", require an identifiable researcher — someone who can confirm the source IP addresses they used and attest in writing that they retained no data. Those are the facts that let us scope an incident accurately, and an anonymous party cannot supply them.

We do not require PGP-encrypted submissions. Plain email is fine. We would rather receive a clear report quickly than a well-encrypted one slowly.

We also publish a machine-readable security.txt at app.depreciationpro.com/.well-known/security.txt and www.depreciationpro.com/.well-known/security.txt, per RFC 9116.

3. Scope

Three separate lists follow. They answer three different questions, and it matters that you read them as three: what you may test, what you must not do, and what we are unlikely to treat as a valid finding. An item on the third list is not unprotected — it is simply not something we will act on.

3a. In scope — assets

Any digital asset owned, operated, or maintained by FirmPro, Inc.

Arbitrary boundaries do not constrain malicious actors and should not constrain you. The following are named as examples of what is included, not as an exhaustive whitelist:

• app.depreciationpro.com — the DepreciationPro application
• The /api/v1 integrator surface
• www.depreciationpro.com — the marketing site

If you are unsure whether something belongs to us, ask before you test it.

3b. Prohibited activities

Prohibited activities include any action that attempts to harm the confidentiality, integrity, or availability of systems, data, or users. Specifically:

• Introducing malware into the system.
• Copying, editing, or deleting data in the system.
• Making changes to the system.
• Repeatedly accessing the system, or sharing access to the system with others.
• Performing brute-force attacks to gain access to a system.
• Performing denial-of-service attacks or social engineering.

And, specific to us:

• Volumetric or load testing of any kind. We are a small team; a load test is an outage.
• Physical testing of offices, facilities, or personnel.
• Anything belonging to a third-party provider. Our infrastructure and integrations include Microsoft Azure, Stripe, Intercom, and Anthropic. We cannot authorise research against systems we do not control — please route those findings to the relevant vendor's own disclosure program. This is a limit on what we are able to grant, not a lack of interest.

3c. Report-quality exclusions

These are things we generally will not treat as valid findings, because they do not demonstrate an exploitable issue. This list exists so our standard is legible rather than arbitrary:

• Automated scanner output with no hand-crafted proof of concept.
• Missing security headers with no demonstrated exploit.
• TLS configuration opinions absent a concrete attack.
• Rate-limiting or volumetric findings.
• Self-XSS.
• Dependency-scanner output without demonstrated exploitability in our deployment.

If you can turn any of the above into a working proof of concept against our deployment, it stops being an exclusion and becomes a finding. Show us the exploit and we will take it seriously.

4. Safe Harbor

When conducting vulnerability research according to this policy, we consider this research conducted under this policy to be:

• Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy;
• Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls;
• Exempt from restrictions in our Terms of Service (TOS) and/or Acceptable Usage Policy (AUP) that would interfere with conducting security research, and we waive those restrictions on a limited basis; and
• Lawful, helpful to the overall security of the Internet, and conducted in good faith.

You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further.

Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties.

Stated once more in the form five national agencies co-sealed on 2026-07-15, because this is the sentence that matters most to you:

If you make a good-faith effort to comply with this policy during your security research, FirmPro, Inc. will consider your research to be authorized, work with you to understand and resolve the issue quickly, and will not recommend or pursue legal action related to your research. Should legal action be initiated by a third party against you for activities that were conducted in accordance with this policy, we will make this authorization known.

The bound on safe harbor

Safe harbor covers research that limits the researcher's exploitation to the minimum amount necessary to confirm the vulnerability's presence. It is further bounded by §5 "If you reach another firm's data" below — please read that section before you begin, not after.

A note on sourcing: this policy is composed from public-domain sources (disclose.io core terms, CC0-1.0) and TLP:CLEAR government guidance, deliberately kept close to the original wording so that it is recognisable rather than bespoke. Organisations adopting similar language should work with their own counsel.

5. If you reach another firm's data

Please read this section before you start testing.

DepreciationPro is multi-tenant. Every account belongs to a CPA firm, and the data inside it is not that firm's own — it is their clients' financial and tax information, held under professional duties of confidentiality. Real client data is in real accounts today. That makes an isolation finding different in kind from every other bug you could report to us: handled well, it is a finding; handled carelessly, it is a breach-notification event for our customers and their clients.

Seven things, in order. None of them is optional and none is boilerplate.

1. Test only your own tenant. Use your own firm account and your own data. Interact only with test accounts you own, or accounts you have explicit permission from the account holder to use. If you need an account to test with, ask us and we will arrange one.
2. The stop condition, spelled out. Once you've established that a vulnerability exists or encounter any sensitive data — including personally identifiable information, financial information, or proprietary information or trade secrets of any party — you must stop your test, notify us immediately, and not disclose this data or information to anyone else. Concretely: do not copy, edit, or delete data in the system. Establishing that you can reach it is the finding. Reaching more of it is not a stronger finding.
3. Purge, then report within 24 hours. Immediately delete every local copy of anything you reached — screenshots, saved response bodies, exported files, notes containing the data, shell history, scratch files. Then contact [email protected] within 24 hours. Do not view, alter, save, store, transfer, or otherwise further access it in the meantime.
4. Do not put the data in the report. Describe what you reached — the shape of it, the route you took, the approximate volume, the kind of record — not a sample of it. A report containing another firm's data is itself a disclosure of that data, and we would have to treat it as one, which is the opposite of what you and we both want. This move carries a second load worth knowing about: for parts of our product, your description may be the primary record of what was reached, so an accurate written description is materially more useful to us than a screenshot. Describe it carefully; you are not being asked to prove less.
5. Here is why, and here is what happens next. We would rather explain this than have it feel like an interrogation. Our customers are CPA firms, and the data belongs to their clients. A confirmed cross-firm read may be a notifiable event on a legal clock, and whether it is turns on facts that, at that moment, only you have. So we will ask you for four things:
   • the source IP address(es) you used,
   • the account identifier(s) you were authenticated as,
   • the approximate volume and nature of what you reached, and
   • a written attestation that you retained nothing.
   Those four facts are what let us scope the event accurately and — where the facts support it — conclude that no customer notification is required. This is the cooperative part: you are, at that point, a party helping us establish what did and did not happen. We will tell you what we concluded.
6. Safe harbor is bounded by this section. Safe harbor covers research that limits exploitation to the minimum amount necessary to confirm the vulnerability's presence. Continuing to access another firm's data after the stop condition in move 2, retaining that data, or declining to provide the facts in move 5, falls outside this policy and therefore outside safe harbor.
7. Do not enumerate other firms to establish scale. If you find an isolation flaw, report it from a single demonstration. Do not repeat it across other firms to establish how widespread it is. We understand the instinct — breadth feels like severity, and it reads well in a write-up — but repeating an isolation flaw across tenants converts one finding into a multi-customer notification event, with a legal clock attached, for every firm you touched. That outcome is worse for our customers than the original bug, and it is not something safe harbor can cover. We will determine prevalence from our own logs. One clean demonstration is a complete report.

In one sentence, for anyone who reads only this section: the two conditions on safe harbor here are an identifiable researcher and a written non-retention attestation — because for a multi-tenant isolation finding, those are what turn "something happened" into a scoped, closable answer.

6. Our Commitments

• Acknowledgement. If you share contact information, we will acknowledge receipt of your report within 3 business days.
• Status. We will keep you informed of remediation progress.
• Remediation. Confirmed vulnerabilities are remediated on the service-level targets already published in our Information Security Program — Critical 48 hours, High 7 days, Medium 30 days, Low 90 days. Those are the remediation ladder and are a separate commitment from the acknowledgement figure above: one governs how fast you hear back from us, the other how fast a confirmed issue is fixed.
• Coordinated disclosure. We ask for a 90-day coordinated-disclosure window measured from the date of our acknowledgement. We would rather agree a timeline than impose one: long embargoes do not necessarily reduce risk, because malicious actors may independently discover the same issue, and if you need a different timeline we will work with you on it.
• No blanket non-disclosure agreements, and no silent fixes. We will not ask you to sign an NDA as a condition of reporting. When we ship a fix for an issue you reported, we will say that a security issue was fixed in our public release notes — a location that does not require a login. You should not have to take our word for it that something was fixed.
• Named credit on request, once a fix has shipped. Tell us how you would like to be credited.
• Sharing expectations. We will keep your report to the people who need it to fix and scope the issue, and we ask that you do the same before public disclosure.

7. Our Expectations

• Minimum report contents: a clear description of the issue and a proof of concept.
• An ideal report additionally carries a minimised proof of concept, a written explanation of the issue, and an assessment of its impact. These are not required — they simply make a report faster for us to validate, which makes your fix faster.
• Limit exploitation to the minimum necessary to confirm the vulnerability's presence.
• Interact only with test accounts you own or have explicit permission from the account holder to use.
• If you are unsure whether something is in bounds, ask us before going any further.

8. No bug bounty

FirmPro, Inc. does not offer monetary rewards for vulnerability reports, and we do not run a hall-of-fame page. This is a deliberate quality decision, and we would rather explain it than leave you guessing.

Since 2025, AI-generated report volume has made monetary incentives a net negative on report quality across the industry. The clearest published data point is the curl project: its rate of confirmed vulnerabilities among submissions fell from over 15% to under 5% under that volume. It shut its bug bounty down on 2026-01-31 — and its count of confirmed vulnerabilities afterwards surpassed the pre-AI level. Fewer submissions, more real bugs, and every reporter got a real answer.

That is the trade we are making. We would rather receive fewer, better reports and answer every one of them properly than pay for volume we cannot triage. It is also why §7 asks for a proof of concept and why §3c lists what we will not act on: if we are going to hold a quality bar, the bar should be written down where you can read it before you spend your time.

What we offer instead: a real answer from a human, on the timeline in §2 and §6; named credit when a fix ships; and the safe-harbor commitment in §4, which is the protection that actually matters when you are deciding whether to look.

9. Questions

If anything in this policy is unclear, or if you are uncertain whether your intended research is consistent with it, email [email protected] before going any further. We would much rather answer a question in advance than have a good-faith researcher guess.