Vendor Security
Questionnaire

How and where is data stored?

Inside your Salesforce org, and nowhere else. Portwood operates no servers, no databases and no hosted service. Everything the application creates is a standard record in your org: templates in DocGen_Template__c and Salesforce Files, generated documents as ContentVersion records attached to the source record, job records in DocGen_Job__c, saved queries in DocGen_Saved_Query__c, and — if you use e-signature — signature requests, signers and audit records in their own custom objects.

Data residency is therefore whatever your Salesforce contract and instance already specify. There is no Portwood-side copy to locate, secure, audit or subpoena.

How is data encrypted?

By Salesforce, using the platform's own controls: TLS 1.2 or higher for every connection to the org, and encryption at rest for stored data. If your org licenses Shield Platform Encryption, it applies to Portwood's fields exactly as it does to any other custom field.

Portwood adds no encryption layer of its own — and, more to the point, no channel that would need one, because data never leaves the platform. Where the application handles a secret directly it hashes rather than stores: signing PINs are held only as SHA-256 hashes and the plaintext is never persisted, and each signed PDF is fingerprinted with a SHA-256 hash recorded on its audit record.

Who owns the data, and what happens to it if the relationship ends?

You own it. Templates, generated documents and every record they are built from are yours, created in your org, under your Salesforce contract. Portwood claims no rights of any kind over customer data; the Apache 2.0 licence covers the software only, and grants rights to you rather than taking any from you.

If the relationship ends, nothing needs to happen, because there is nothing on our side to return or destroy. If you uninstall the package, Salesforce removes its components and the records held in its custom objects; documents already generated are ordinary Salesforce Files and stay in your org untouched, as do the source Word templates you hold outside the system. The licence does not end either — Apache 2.0 is irrevocable, so your right to keep running the version you have installed survives any commercial disagreement or change of direction on our part.

When data is deleted, is it permanently erased?

Deletion follows Salesforce's own semantics: deleted records sit in the Recycle Bin for 15 days and are then purged, or you can hard-delete immediately. Because Portwood keeps no copies, backups, caches or logs anywhere outside your org, there is no second location in which deleted data can survive — the usual hard part of this question does not arise.

Material a customer voluntarily shares with support — an example template or a sample document — is treated as confidential and deleted when the issue is closed.

How is data recovered in the case of loss?

Through your Salesforce recovery options: the Recycle Bin, your own backup and restore tooling, or Salesforce's recovery services — the same path as for any other data in the org. We cannot restore your data, for the same reason we cannot lose it.

What we can always restore is the software and its configuration. Every released version remains retrievable from Salesforce's package infrastructure, and the complete source history is public, so templates and configuration can be rebuilt from scratch if it ever comes to that.

Does Portwood collect telemetry, usage information, crash data or logs outside our org?

The application itself transmits nothing: no telemetry, no usage analytics, no crash reporting, no log shipping of any kind.

Salesforce itself provides AppExchange publishers with standard licensing and adoption information through its License Management framework — essentially which orgs have installed the package, the installed version, and licence status. That is Salesforce-operated telemetry about the installation, not access to anything inside your org, and it is identical for every AppExchange package you have ever installed. No customer records, documents, templates or field data are ever visible to Portwood through any channel.

Will any third parties have access to our data?

No. The application shares data with no one: no subprocessors, no analytics provider, no external API, no CDN. There is no mechanism in the package by which a third party could receive your data even if we wanted them to.

Two adjacent points, stated plainly rather than left to be discovered. If you use our Slack support channel, Slack hosts what you choose to post there — and only that. If you engage our contracted delivery team, those named individuals see your org only through accounts you create and control; that is covered under People & access.

How is access to data enforced inside the application?

By your org's own security model. Portwood runs as the logged-in user and honours object permissions, field-level security and sharing rules; those checks run through a central enforcement layer in the code rather than being scattered ad hoc, which is one of the things Salesforce's security review examines. A user who cannot see a record in Salesforce cannot merge it into a document.

Which users get the application at all is your administrator's decision, made through the permission sets shipped in the package: Portwood Admin for template authors and configuration, Portwood User for people who generate documents, plus narrow sets for quick actions, button management and the guest signing runtime. Nobody gains access by the package merely being installed.

There is one documented exception to the user-context rule, and it is deliberate: the optional guest signing page. It does not work by granting guest users access to objects — it works by binding every operation to a cryptographic capability token. That model is set out in full below.

Does the application make external callouts or rely on third-party libraries, APIs or CDN-hosted resources?

No external services, APIs or CDN-hosted resources. At runtime the application loads nothing from outside Salesforce. The package contains no HTTP callouts, no API client, no named credentials and no remote site settings — all of which you can verify in the published source before installing, rather than take on trust.

The package does bundle a small number of open-source JavaScript libraries as static resources inside the package itself — pdf.js and pdf-lib for client-side PDF handling, and Chart.js for chart rendering. They are served from your Salesforce org like every other package component, version-pinned at package build time, and covered by the same AppExchange security scanning as our own code. Server-side PDF rendering uses Salesforce's own native Visualforce rendering engine — a platform capability, not a third-party service.

How often do you scan for vulnerabilities, and are there open findings?

Salesforce Code Analyzer runs against the codebase for every release — currently every other Friday. The present result is zero open findings at every severity: no Critical, no High, no Medium, no Low. Salesforce runs its own scanning independently as part of the AppExchange security review.

The current build status, including the automated test suite and analyzer results, is published openly on our GitHub repository, and we will provide the raw scan output for the specific version you install rather than asking you to accept a summary.

What version was covered by the most recent AppExchange Security Review, and when was it completed?

The most recent security review was for version 3.0.0 and was approved on 18 June 2026.

For context on how this works: Salesforce Security Review approves the package and its namespace for AppExchange distribution. Subsequent releases are distributed under that approval and remain subject to Salesforce's ongoing partner security obligations and periodic re-review requirements. Every release, regardless of where it falls in the review cycle, goes through the automated scanning and test suite described above.

Salesforce does not issue a customer-distributable report for the review — approval is the artifact, and the listing remaining live on the AppExchange is its ongoing evidence. What we can hand you directly: the Code Analyzer output for your version, the automated test results (1,905 Apex tests passing at 78% coverage as of 3.56.0), and the complete source code, which your own team or a firm of your choosing may review line by line.

Has the application been independently penetration tested outside the AppExchange review?

No. We have not commissioned a separate third-party penetration test beyond the Salesforce AppExchange Security Review, and we would rather state that plainly than let a scanning summary imply otherwise.

Two things are worth weighing against it. The complete source code is public under Apache 2.0, so your team — or a firm you commission — can perform a direct code review of exactly what you would run, which is a stronger position than most vendors can offer. And if a scoped penetration test of the e-signature guest surface is a requirement for your approval, we are open to discussing it.

What security practices govern development, and what prevents a breach reaching us through you?

The largest control is architectural, and it is the one we would keep if we could only keep one: there is no Portwood-operated system holding customer data, so there is no vendor breach that could expose it. An attack on us cannot reach you, because nothing of yours is here.

On top of that:

• Source control. A GitHub organization with MFA enforced and branch protection on the release branch; every change reviewed before merge and permanently public afterwards.
• Least privilege. The application runs in the context of the logged-in user; guest users are never granted object access.
• No secrets in source. There are no credentials, keys or endpoints to leak — the package calls nothing.
• Static analysis with Salesforce Code Analyzer before release, measured against the current ruleset rather than the one in force when the code was written.
• Dependency pinning. Bundled libraries are fixed at build time and scanned with the rest of the package.
• Hashing over storage. Signing PINs are stored only as SHA-256 hashes; signed documents carry a SHA-256 fingerprint.
• Salesforce ISV security requirements, which the package must continue to satisfy to remain on the AppExchange.
• MFA on all business systems, and no customer records stored on company endpoints.

How often is the software updated, and who controls when an upgrade is installed?

Releases go out every other Friday, each one listed in the public changelog. You decide when, or whether, to install one.

The complete answer on push upgrades, including the part vendors usually leave out: the Salesforce managed package framework does technically permit publishers to push upgrades to subscriber orgs. Our policy is that we do not push feature upgrades — customers control when upgrades are installed. We reserve push upgrades solely for critical security patches, where rapid remediation across all customers is in every customer's interest. Push upgrades under the Salesforce framework cannot change your data, your configuration or the package's permission footprint; they can only deliver a patched version of existing components.

What are your remediation timelines for Critical and High vulnerabilities?

Our release cadence is every other Friday, and we commit to these targets:

Under what circumstances would Portwood personnel need access to our Salesforce environment?

Only when you engage us for implementation or support work that requires it, and then case by case. There is no standing access, no background connectivity, and no access mechanism built into the application itself.

Any access exists solely as a named user account you create. Much support work — template questions, troubleshooting, configuration guidance — is routinely handled with no environment access at all; customers share templates and screenshots through our support channel instead.

Can implementation and support be performed in a sandbox using sample or masked data?

Yes. Sandbox-first is the standard and preferred practice, and template development in particular never requires production data. Production access would only arise for a final deployment step or a production-specific issue, at your request, and can be limited to the shortest window you are comfortable with.

During implementation, how is data transmitted?

It isn't. Implementation work is performed inside your Salesforce org through a named user account you create, normally in a sandbox, and template development uses sample or masked data. The artifacts that actually move between us are templates and configuration — Word files, query configuration, screenshots — exchanged through your support channel. Exports of your records are not part of the work and are not requested.

Are the individuals who may access customer environments employees, contractors, or both? What controls apply to them?

Both. Engagements are led by Portwood's principal consultant, and delivery work may be performed by our contracted implementation team, which operates under a written delivery agreement with Portwood that includes confidentiality obligations covering customer information.

Access termination is structural rather than procedural, which we think matters more than a policy statement: because every account is provisioned in your org, you hold unilateral, immediate revocation at all times. We instruct account deactivation at the close of each engagement, but you never have to rely on us doing it.

Do you maintain a list of subcontractors that could have access to customer systems, and would we be notified if it changes?

Yes. We currently use a single delivery firm for contracted implementation work, and we will identify it — and the specific individuals assigned to your engagement — on request. We will notify you before any new subcontractor is given access to your environment.

As a practical control underneath that commitment: no subcontractor can gain access without you creating an account for them, so no change to our roster can affect your environment without your direct participation.

Are personnel prohibited from downloading or retaining customer information outside our environment?

Yes. Our policy is that all work is performed inside the customer's environment; personnel are prohibited from exporting, downloading or retaining customer records outside your Salesforce org.

The nature of the work makes this straightforward to hold to: the work product of our engagements is templates and configuration, not data, and template development uses sample data. Where a customer shares an example document or template with us through a support channel, we treat it as confidential and delete it when the issue is resolved.

How long are support or implementation accounts normally left active?

They should be deactivated when the engagement completes, and that is what we ask customers to do. We do not request or rely on standing access for ongoing support.

If a future support issue requires environment access, we ask you to reactivate or reprovision an account for that specific issue. You are free to enforce a shorter window than that — some customers time-box access to the working session itself, which we are happy to work within.

Have you had any breaches or security issues in the past?

No. Portwood has had no security breach, no unauthorized access to a customer environment, and no security incident requiring customer notification. There are no open Critical or High findings in the current release.

What system monitoring procedures are in place?

Monitoring of the environment where your data lives is Salesforce's and yours: Login History, Setup Audit Trail, and Event Monitoring if your org licenses it. Portwood's activity appears in those logs like any other application — including anything done by a named account we are given, which is a control you hold rather than one you have to ask us about.

On our side we monitor the GitHub organization's audit log, and security@portwood.dev is the monitored intake for reports from customers or researchers. Separately, the e-signature module writes its own audit record for every signature: signer name and email, timestamp, IP address, user agent, verification method, consent capture, and a SHA-256 hash of the signed document.

Do you have an incident response plan, and what is the customer notification timeframe?

We maintain an incident response process appropriate to our size and architecture: intake via security@portwood.dev, triage and severity classification, remediation delivered as a package release, and customer notification.

The notification commitment is specific rather than "without undue delay": affected customers are notified within 72 hours of our confirming a security incident that affects them, with preliminary details and the remediation path.

How do you inform customers about security issues generally?

Security-relevant fixes are described in the public changelog and release notes. Where an issue affects a specific customer, we notify that customer directly on the timeline above. Critical patches may be delivered as a push upgrade — the one circumstance in which we upgrade an org without waiting.

Reports in the other direction come to security@portwood.dev, which is monitored independently of any one person's availability.

Who is responsible for your cyber security, and is there backup coverage for that role?

Portwood has a designated security officer, accountable for vulnerability triage, incident response and release security, reachable at security@portwood.dev. That address is monitored independently of any individual.

Technical remediation capability is held by the delivery engineering team as well, so the role is not a single point of failure — that team works in the codebase daily and can produce and ship a fix independently. The open-source model is itself a key-person mitigation: the complete, current codebase is publicly available at all times, so no proprietary knowledge can be lost with any individual.

How do you stay current on the security landscape?

Not through an annual certification exercise, and we would rather say so than dress one up. Currency comes from the obligations of the work itself: maintaining an AppExchange package requires tracking Salesforce's partner security requirements and the security changes in each of the three annual platform releases — guest user policy above all, which Salesforce has tightened repeatedly and which we have had to follow each time. Static analysis rules update with the analyzer, and every release is measured against the current ruleset.

The structural piece is that the codebase is public. Review is continuous and comes from outside as well as inside, which is a harder standard than an internal team reviewing its own work once a year.

Do you have a current SOC report? If not, what documentation covers your internal operations?

Not one of our own, and we would rather explain that than imply otherwise. A SOC 2 attests to controls over systems that hold customer data; Portwood operates none. The systems that hold your data are Salesforce's, and Salesforce's SOC 1, SOC 2 and SOC 3 reports cover them — available to you directly as a Salesforce customer through their compliance portal, and almost certainly already on file at your firm.

For Portwood's own operations we provide a written controls narrative covering:

• Source code management. GitHub organization with MFA enforced, branch protection, and a full public audit history of every change. Our development process is unusually transparent, because the entire commit history is open to you.
• Release process. Automated test suite and static analysis before every release; distribution exclusively through Salesforce's package infrastructure.
• Corporate system access. MFA on all business systems.
• Contractor governance. Written agreement with confidentiality obligations; customer-provisioned access only.

We are also willing to complete your firm's own controls documentation or answer targeted follow-ups. For an organization of our size and architecture, a direct controls narrative is more informative than a formal audit of systems that hold no customer data.

Do you have physical data protection measures in place?

Customer data exists only in Salesforce data centres, whose physical controls are covered by Salesforce's SOC and ISO certifications — the same physical security already protecting your CRM, not a second standard to evaluate.

On our side there is no server room and no customer data to protect physically. Our own work happens inside Salesforce too — the environment we work in is the customer's org, not a local copy of it — so customer records never land on a workstation in the first place. Company endpoints require full-disk encryption, screen lock and MFA.

Do you have a disaster recovery or business continuity plan?

Yes, scaled to how the product actually works. Continuity of the application does not depend on Portwood's operations at all: the package is hosted and distributed by Salesforce, it runs inside your org, and the source is permanently public. An outage or disruption at Portwood cannot interrupt your use of it.

Continuity of services rests on three things. A contracted delivery team of meaningful depth — our delivery partner maintains a bench of roughly 35 Salesforce professionals, so support and maintenance capacity is not tied to any single individual. Source code, issue tracking and documentation maintained in GitHub and accessible to that team. And security response reachable through security@portwood.dev, monitored independently of any one person's availability.

If Portwood were no longer operating, how would we receive future security fixes or compatibility updates?

Three layers, in order of likelihood.

• The delivery engineering team operates under a continuing commercial agreement and could maintain the codebase and releases independently of any single individual at Portwood.
• The source code is permanently available under Apache 2.0, so any Salesforce partner or in-house developer you choose could patch, rebuild and deploy the application. The licence grants you that right irrevocably — which functions as built-in source code escrow, without an escrow agent to fail you.
• Salesforce's own backward-compatibility practices mean installed managed packages continue functioning across platform releases. Salesforce versions its APIs precisely so that existing packages do not break.

Do you carry cyber security or liability insurance?

Yes. Portwood carries technology errors & omissions and cyber/privacy liability coverage. We will provide a current certificate of insurance, showing coverage and limits and naming your firm as certificate holder, on request.

Can you provide references who will discuss their experiences?

Yes — we will introduce you to customers running Portwood in production who are willing to talk, and we try to match the reference to your situation rather than send whoever is nearest to hand.

Before that call, there is public evidence you can read without asking us for anything: every AppExchange review of Portwood is republished on this site unfiltered, each one with a named reviewer, and verifiable against the AppExchange listing itself.