Architecture, requirements, usage

Yes. Shipped executable components such as PowerShell scripts and DLLs are signed with an Extended Validation code-signing certificate. SHA-256 release hashes are published for release archives, and each release includes hashes.txt with per-file hashes so integrity can be verified before use.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/

Yes. The add-on is delivered within the same release ecosystem and uses the same documented integrity controls for shipped executable components: Extended Validation code signing, SHA-256 release hashes, and hashes.txt with per-file hashes. The Outlook add-in is additionally deployed in a version-controlled manner under customer administrative control.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://set-outlooksignatures.com/outlookaddin

Integrity is verified before deployment by checking the published SHA-256 hash for the release archive, validating the per-file hashes in hashes.txt, and verifying the digital signatures on shipped executable components such as PowerShell scripts and DLLs.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/

Integrity is verified before deployment through the same controls used for the shared release package: SHA-256 release hashing, per-file validation through hashes.txt, and code signing of shipped executable components. For the Outlook add-in, integrity and change control are additionally supported through customer-managed hosting and explicit version-controlled deployment.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://set-outlooksignatures.com/outlookaddin

Yes, in practical terms. Set-OutlookSignatures is shipped as a self-contained collection of software, and the deps folder acts as a practical SBOM because it contains one subfolder per dependency. The main script, configuration files, and files in the sample code folder are also documented both in the public documentation and within the files themselves.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://set-outlooksignatures.com/details, https://set-outlooksignatures.com/help

Yes, by dependency on the base package. The add-on does not introduce a separate general dependency inventory beyond Set-OutlookSignatures itself, so the dependency transparency of the underlying Set-OutlookSignatures package also covers the runtime foundation of the add-on.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases

Set-OutlookSignatures is shipped as a self-contained package. Third-party dependencies are included in the package itself, primarily in the deps folder, where one subfolder corresponds to one dependency, making the dependency set transparent and reviewable. Dependencies are included only in specific reviewed versions in the distributed package.

Dependency changes are documented in versioned releases, and the package is distributed with hashes and code signing so it can be reviewed before deployment.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://set-outlooksignatures.com/details

The add-on does not introduce a separate additional third-party dependency stack beyond the dependency foundation already delivered with Set-OutlookSignatures, except for the Outlook add-in, which has its own npm and JavaScript-based dependencies. Those are likewise shipped in specific reviewed versions and maintained through the same controlled release process.

Relevant URLs: https://set-outlooksignatures.com/outlookaddin, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases

Every upstream dependency is included in a specific, hand-selected version as part of the shipped package. Dependency vulnerabilities are monitored regularly and manually, supported by GitHub Dependabot, Renovate, and Snyk, and by reviewing relevant security-focused websites and newsletters. When an issue is identified, the affected dependency is updated to a reviewed version and shipped in a new release of the self-contained package.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/docs/CHANGELOG.md

The same principles apply to the add-on. The Outlook add-in has its own npm and JavaScript-based dependencies, which are also monitored regularly and manually, supported by GitHub Dependabot, Renovate, and Snyk, and by reviewing relevant security websites and newsletters. When an issue is identified, the affected dependency is updated to a reviewed version and shipped in a new release.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://set-outlooksignatures.com/outlookaddin

Set-OutlookSignatures normally runs in the security context of the logged-on user. In standard client mode, day-to-day execution is therefore user-context, not local administrator context. For on-premises client-side use, no Graph registration is required. Where Graph-backed scenarios are used, Entra ID administrator rights are only required once to create and consent the required Entra ID app during setup. After that one-time setup, normal operation is designed to run in user context.

The detailed permission model is documented here: https://set-outlooksignatures.com/details#security-considerations

The add-on supports two permission models, depending on deployment mode. In client mode, it follows the same model as Set-OutlookSignatures and runs in the security context of the logged-on user. In SimulateAndDeploy mode, it runs centrally in the security context of a service account and requires temporary full access to the target user mailboxes to create and deploy signatures and out-of-office settings centrally. The Outlook add-in itself runs in the security context of the user. Where Exchange Online is used, Entra ID administrator rights are only required once during initial setup to create and consent the required Entra ID apps.

The detailed permission model is documented here: https://set-outlooksignatures.com/details#security-considerations, https://set-outlooksignatures.com/outlookaddin

Persistent configuration and content changes are made where directly required for the function of the software, but the product does not require or inherently auto-create scheduled tasks or startup scripts. It can be run via logon script, scheduled task, or other customer-selected deployment mechanisms, depending on how the customer chooses to operate it.

It writes signatures to the local Outlook signature store and can also persist signature content to additional configured locations. In Classic Outlook for Windows, it can also set user-level HKCU registry values where required for signature handling.

Relevant URLs: https://set-outlooksignatures.com/features, https://set-outlooksignatures.com/details, https://set-outlooksignatures.com/faq

The add-on follows the same principle, but with additional persistent changes in mailbox-based and centralized deployment scenarios. It does not inherently require or auto-create scheduled tasks or startup scripts, although it can be operated through customer-chosen mechanisms such as logon scripts, scheduled tasks, or central execution models.

In client mode, it can make the same kinds of persistent local changes as Set-OutlookSignatures. In addition, it can persist signatures and related data to Outlook Web, roaming signatures, Drafts, additional signature paths, and mailbox-resident data used by the Outlook add-in. In SimulateAndDeploy mode, it primarily makes mailbox-side persistent changes rather than end-user device changes. The Outlook add-in is deployed through manifest-based add-in deployment and customer-managed hosting rather than startup scripts.

Relevant URLs: https://set-outlooksignatures.com/details, https://set-outlooksignatures.com/outlookaddin

Code execution is protected through code signing, hash-based integrity verification, and customer-controlled deployment. Shipped executable components such as PowerShell scripts and DLLs are digitally signed with an Extended Validation code-signing certificate, and each release includes a SHA-256 hash for the release archive together with hashes.txt containing per-file hashes. This allows customers to verify that the package and executable files have not been altered before execution or deployment.

Set-OutlookSignatures is also delivered as a self-contained package with included, version-pinned dependencies, so code execution does not depend on uncontrolled live dependency retrieval at runtime. The quickstart explicitly supports the use of application control solutions by trusting the existing digital file signature.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://set-outlooksignatures.com/quickstart, https://set-outlooksignatures.com/details

The same protection principles are used for shipped executable components: Extended Validation code signing, SHA-256 release hashing, per-file hashes in hashes.txt, and customer-side verification before deployment. Because the add-on depends on Set-OutlookSignatures, it benefits from the same self-contained, version-pinned packaging approach for the underlying execution base.

For the Outlook add-in, protection against tampering is additionally supported by customer-managed hosting, explicit version-controlled deployment, and manifest-based rollout. This means the customer controls which add-in files are published, from which host they are served, and when a new version is made available to clients.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://set-outlooksignatures.com/outlookaddin

Yes. Set-OutlookSignatures is subject to manual code review and the codebase is available for peer review as part of the open-source development model. The core is described as peer-reviewable and audit-ready, and the full source code, release history, and security process are published openly.

Static analysis practices are also used in development. The main PowerShell code explicitly contains PSScriptAnalyzer-related suppressions, which reflects the use of PowerShell static analysis during development and review. A published security policy defines responsible disclosure and remediation. A separate statement about formal third-party penetration testing or formal DAST is not published in the reviewed materials.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/security, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/src_Set-OutlookSignatures/Set-OutlookSignatures.ps1

Yes. The add-on is subject to manual code review and the same general engineering and review discipline used across the Set-OutlookSignatures ecosystem. The shared core is openly reviewable and described as peer-reviewable and audit-ready, and the published security policy governs vulnerability handling and remediation.

For the Outlook add-in, code and dependencies are maintained through the same controlled release and review process, including documented dependency maintenance and security hardening in the release history. A separate statement about formal third-party penetration testing or formal DAST for the commercial add-on is not published in the reviewed materials.

Relevant URLs: https://set-outlooksignatures.com/outlookaddin, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/security

Set-OutlookSignatures is maintained as the open-source upstream project. The commercial provider does not operate a separate public commercial fork of the community core. Instead, the upstream ecosystem is supported through sponsorship, code donations, professional support, and additional testing and enhancement resources. A publicly documented example is the INI editor, which was donated into the ecosystem. The released software is also signed with the provider’s certificate.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/, https://set-outlooksignatures.com/blog/2026/05/01/v4-27-0, https://explicitconsulting.at/open-source, https://set-outlooksignatures.com/quickstart

The add-on is not positioned as a separate public fork of Set-OutlookSignatures. It is provided as a proprietary commercial add-on that builds on top of Set-OutlookSignatures. The broader ecosystem is supported with code donations, the code-signing certificate, and additional development and test resources.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://explicitconsulting.at/open-source, https://set-outlooksignatures.com/blog/2026/05/01/v4-27-0

Upstream updates are incorporated by selecting specific reviewed versions of dependencies and bundling them into the self-contained release package rather than relying on uncontrolled runtime retrieval. Releases are created from versioned tags on the stable branch, dependency and functional changes are documented in the release notes and changelog, and the resulting package is published as a signed, hash-verifiable release.

Upstream changes are validated through the normal engineering process, including manual review, separate development and test environments, and documented release packaging.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/docs/CHANGELOG.md

Upstream updates from Set-OutlookSignatures and from add-on and Outlook add-in dependencies are incorporated by selecting specific reviewed versions, bundling them into controlled releases, and documenting the resulting changes in the release history. There is no reliance on uncontrolled live dependency updates in production. For the Outlook add-in, explicit version-controlled deployment is used, where configuration or code changes require a new version to be published and deployed.

These updates are validated through the same controlled engineering and release process used across the ecosystem. For the Outlook add-in, the documentation recommends separate testing and production hostnames so updated versions can be validated before broad rollout.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://set-outlooksignatures.com/outlookaddin

None. Set-OutlookSignatures does not require any access to the customer environment. It is designed for self-hosted, customer-controlled operation with zero external data processing and no mail rerouting. The software does not phone home. Any permissions required by the software itself within the customer environment are covered separately in the permission-related questions and are not vendor access requirements.

Relevant URLs: https://set-outlooksignatures.com/features, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/

None. The add-on does not require any access to the customer environment. It is designed for customer-controlled deployment with zero external data processing, no mail rerouting, and software that does not phone home. The Outlook add-in is self-hosted by the customer, and normal operation does not require any inbound vendor access or external processing by the provider. Any permissions required by the software itself within the customer environment are covered separately in the permission-related questions and are not vendor access requirements.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://set-outlooksignatures.com/outlookaddin

No. Support scripts and auxiliary tools are provided within the open-source project itself, not beyond it. Examples include the documented sample code, the Create-EntraApp.ps1 helper used during setup, and the INI editor, all of which are part of the documented Set-OutlookSignatures ecosystem.

Relevant URLs: https://set-outlooksignatures.com/details, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases

Yes. Additional tools and components are introduced beyond the open-source project as part of the commercial add-on. These include the Outlook add-in, its deployment and build tooling such as run_before_deployment.ps1, its configurable add-in code including CustomRulesCode.js, and the associated customer-hosted add-in deployment model.

Relevant URLs: https://set-outlooksignatures.com/outlookaddin, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases

Set-OutlookSignatures accesses the data sources required to generate and deploy signatures in the customer environment. This includes on-premises Outlook and mailbox context, Active Directory, and, where configured, Entra ID and Microsoft Graph for user, mailbox, manager, group, and replacement-variable data. If the customer stores templates or configuration files there, SharePoint Online can also be used. The architecture also supports other customer-controlled sources such as APIs, LDAP, databases, and files through custom logic and replacement-variable configuration.

Relevant URLs: https://set-outlooksignatures.com/details, https://set-outlooksignatures.com/features

The add-on accesses the same underlying customer-controlled data sources as Set-OutlookSignatures and, where the add-on features are used, also Exchange Online, Outlook Web signature data, roaming signatures, Drafts-based signature collections, and mailbox-resident data used by the Outlook add-in. The Outlook add-in reads signature information written to the user’s mailbox by the add-on.

Relevant URLs: https://set-outlooksignatures.com/details, https://set-outlooksignatures.com/outlookaddin

Only the permissions needed for the features and deployment model in use are required. The required permissions are documented centrally in the security considerations, and only the minimum necessary permissions should be granted for the selected scenario. For the detailed and authoritative permission matrix, please refer to https://set-outlooksignatures.com/details#security-considerations.

Only the permissions needed for the features and deployment model in use are required. This includes the documented permission model for the base software plus the additional requirements for add-on deployment scenarios such as the Outlook add-in and, where used, centralized SimulateAndDeploy operation. For the detailed and authoritative permission matrix, please refer to https://set-outlooksignatures.com/details#security-considerations and https://set-outlooksignatures.com/outlookaddin.

The data needed for signature generation is processed and stored within the customer’s own environment. Directory or user data is not transmitted externally to the vendor or to third-party cloud signature services. Depending on configuration, generated signature data may be stored locally in the Outlook signature store and, if configured, in an additional customer-controlled location such as the user’s Documents folder, a synchronized path, a file share, or SharePoint.

Information about credentials, tokens, or other logon information storage is addressed separately in the dedicated question on how credentials or tokens are stored and protected.

Relevant URLs: https://set-outlooksignatures.com/features, https://set-outlooksignatures.com/details

The data needed for signature management is also processed and stored within the customer’s own environment. Directory or user data is not transmitted externally to the vendor or to third-party cloud signature services. In addition to the storage options already available through Set-OutlookSignatures, the add-on may store signature-related data in customer-owned mailbox locations such as Outlook Web signature data, roaming signatures, Drafts-based signature collections, and mailbox-resident data used by the Outlook add-in.

Information about credentials, tokens, or other logon information storage is addressed separately in the dedicated question on how credentials or tokens are stored and protected.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://set-outlooksignatures.com/outlookaddin, https://set-outlooksignatures.com/details

Integrated Windows Authentication is used for access to Active Directory. For access to Microsoft Graph, Microsoft Authentication Library for .NET is used with a sequence of non-interactive and interactive authentication methods, depending on what is available and appropriate in the customer environment. The FAQ documents the Graph authentication flow and token cache location.

On Windows, MSAL for .NET stores user names and refresh tokens by using Microsoft DPAPI, which means the protected data can only be decrypted by the same user on the same device. On macOS and Linux, MSAL uses comparable platform keychain or keyring mechanisms. Credentials and tokens are not transferred to the vendor, and all authentication remains within the customer-controlled environment.

Relevant URLs: https://set-outlooksignatures.com/faq#which-graph-authentication-methods-are-used, https://set-outlooksignatures.com/faq, https://set-outlooksignatures.com/details#security-considerations

The add-on does not implement a separate authentication module. For core authentication to Active Directory and Microsoft Graph, it relies on the same authentication model used by Set-OutlookSignatures. For the Outlook add-in, Microsoft Authentication Library for JavaScript is used together with Outlook’s authentication API. Outlook itself is therefore responsible for the handling and storage of credentials and tokens for the add-in scenario. Authentication remains within the customer-controlled environment, and credentials or tokens are not transferred to the vendor.

Relevant URLs: https://set-outlooksignatures.com/outlookaddin, https://set-outlooksignatures.com/details#security-considerations, https://set-outlooksignatures.com/faq#which-graph-authentication-methods-are-used

Arbitrary live GitHub changes are not deployed directly into productive environments. Changes are reviewed in separate development and test environments before deployment is recommended or performed. No code change is released without accompanying documentation, at minimum in the changelog that is part of the release. Deployment is therefore based on a reviewed, documented, versioned release package rather than on an uncontrolled repository state.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/docs/CHANGELOG.md

The add-on is not provided through GitHub; it is a closed-source commercial add-on. Development goes hand in hand with Set-OutlookSignatures, and changes are reviewed and validated in separate development and test environments before deployment. Productive deployment is based on reviewed package versions, not on an uncontrolled live development state. No code change is released without accompanying documentation, at minimum in the changelog that is part of the release.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/docs/CHANGELOG.md

Yes. A version pinning strategy is used. The software is self-contained, so the customer decides which released version to use in production. Semantic versioning is followed. Information about dependency version pinning is addressed separately in the dedicated question about third-party dependencies.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://set-outlooksignatures.com/quickstart

Yes. A version pinning strategy is used. The software is self-contained, so the customer decides which released version to use in production. Semantic versioning is followed. The add-on must be used in the same version as Set-OutlookSignatures. Information about dependency version pinning is addressed separately in the dedicated question about third-party dependencies.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases

Yes. Updates are tested in separate development and test environments before rollout. A change is not treated as rollout-ready until it has been validated in those environments and documented as part of a release. No released code change is shipped without accompanying release documentation, at minimum in the changelog.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/docs/CHANGELOG.md

Yes. Updates are tested in separate development and test environments before rollout. Development goes hand in hand with Set-OutlookSignatures, although parts of the configuration may be aligned for specific use and test cases. The add-on is also tested in the provider’s own production environment before release. A change is not treated as rollout-ready until it has been validated in those environments and documented as part of a release. For the Outlook add-in, the documentation additionally recommends separate testing and production hostnames for pre-rollout validation.

Relevant URLs: https://set-outlooksignatures.com/outlookaddin, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/docs/CHANGELOG.md

Yes. Updates are validated for security issues before being recommended. This includes manual review, review in separate development and test environments, and regular dependency and security monitoring supported by tools such as GitHub Dependabot, Renovate, and Snyk, together with review of relevant security-focused websites and newsletters. No released code change is shipped without accompanying documentation, at minimum in the changelog that is part of the release.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/docs/CHANGELOG.md

Yes. Updates are validated for security issues before being recommended. This includes manual review, review in separate development and test environments, regular dependency and security monitoring supported by GitHub Dependabot, Renovate, and Snyk, and review of relevant security-focused websites and newsletters. The add-on is also tested in the provider’s own production environment before release. No released code change is shipped without accompanying documentation, at minimum in the changelog that is part of the release.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/docs/CHANGELOG.md

Set-OutlookSignatures is licensed under the European Union Public Licence version 1.2. The open-source license applies to the base software. Under the EUPL, the software may be used, reproduced, modified, distributed, and communicated, subject to the conditions of the license. These conditions include preserving copyright and license notices, complying with the EUPL’s reciprocity obligations when distributing original or derivative works, and providing the source code or a repository reference when distributing the software. The software is provided on an as-is basis under the EUPL.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/license.txt, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/

The add-on and Outlook add-in are provided under a commercial proprietary license, and the provider’s Terms of Service and General Terms and Conditions apply at https://explicitconsulting.at/legal. The proprietary license applies only to the add-on and its components and does not extend from the open-source Set-OutlookSignatures base software. Use is granted exclusively to active licensees, the license is non-transferable, and redistribution is prohibited. Unauthorized copying, modification, distribution, or reverse engineering is prohibited. The right to use the software terminates automatically if the license terms are violated or if the active license expires or is cancelled. The public licensing information also states that licensing is per mailbox, billed annually in advance, and without auto-renewal.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://explicitconsulting.at/legal, https://explicitconsulting.at/support-terms

The Set-OutlookSignatures community project does not provide indemnification or a formal support SLA. Community support is available through the public project channels, and professional support can be obtained separately if desired.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/, https://explicitconsulting.at/support-terms

A separate public indemnification commitment is not published in the reviewed public terms. Professional support is provided, but the public terms make clear that support is not included in the add-on license itself. Publicly documented support conditions include prioritized support requests for license holders, availability Monday to Friday on Austrian business days by email and callback, and optional 24/7 and on-call support on request. A separate public SLA document is not published in the reviewed sources.

Relevant URLs: https://explicitconsulting.at/support-terms, https://set-outlooksignatures.com/benefactorcircle, https://explicitconsulting.at/legal

Yes. Redistribution and modification are permitted under the European Union Public Licence version 1.2, but they come with license obligations. When redistributing the original work or derivative works, the applicable copyright and license notices must be preserved, the EUPL terms must be respected, and the corresponding source code or a repository reference must be provided as required by the license. The EUPL also contains reciprocity obligations for distributed derivative works.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/license.txt, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/

Yes. Redistribution and modification are not permitted for the add-on and Outlook add-in except as expressly authorized by the commercial license. The proprietary license states that unauthorized copying, modification, distribution, or reverse engineering is strictly prohibited, that the license is non-transferable, and that the software may not be sublicensed, rented, or leased to third parties. It also states that redistribution of the software or its components is prohibited and that use is subject to the legal terms at https://explicitconsulting.at/legal.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://explicitconsulting.at/legal

Infrastructure exposure is minimized by design. Set-OutlookSignatures is self-hosted, self-contained, and does not require a vendor-operated cloud signature relay that would process customer directory or mail data on the vendor side.

The project and release side are protected through digitally signed executable components, SHA-256 release hashes, per-file hashes, a published security policy and responsible-disclosure process, and a controlled release process with separate development and test environments.

For the systems used for development, build, release, and project administration, controls include one user equal to one physical person, role-based access control, least privilege, need to know, multi-factor authentication, backups, restore tests, and recurring audit log analysis. Specific reviewed dependency versions are used, regular security monitoring is performed, and no released code change is shipped without accompanying documentation, at minimum in the changelog.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/security, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/docs/CHANGELOG.md

Systems and infrastructure are protected through a control model that follows well-known service-management and information-security practices and frameworks, for example ITIL and ISO/IEC 27001-aligned controls, for engineering, release, support, and operations. This includes controlled development and release management, separate development and test environments, documented changes, controlled support processes, and secure handling of customer support artifacts.

Internal controls include one user equal to one physical person, role-based access control, least privilege, need to know, multi-factor authentication, backups, restore tests, recurring audit log analysis, conditional access policies, risk-based access policies, and managed-devices-only access for relevant administrative and business-critical scenarios.

Exposure is additionally minimized by product design. The add-on and Outlook add-in are self-hosted and customer-controlled, use no middleware or proxy servers, perform no external data processing, and do not phone home. Signed and hash-verifiable release artifacts, dependency monitoring and reviewed updates, and secure data exchange for support logs through a secure portal are also used.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://set-outlooksignatures.com/outlookaddin, https://explicitconsulting.at/legal, https://explicitconsulting.at/support-terms

Own data and information are protected by applying role-based access control, least privilege, need to know, and one user equal to one physical person as core access principles. Multi-factor authentication, backups, restore tests, and recurring audit log analysis are additionally used to protect the systems and data used for development, build, release, and project administration.

Confidentiality exposure is also minimized by design because Set-OutlookSignatures is self-hosted, customer-controlled, and does not require customer data to be processed in the vendor environment. On the release side, integrity and confidentiality are protected through digitally signed executable components, SHA-256 release hashes, per-file hashes, controlled releases, and a published security process.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/security, https://set-outlooksignatures.com/features

Own data and information are protected through a control model that follows well-known service-management and information-security practices and frameworks, for example ITIL and ISO/IEC 27001-aligned controls, for engineering, release, support, and operations. Within that model, role-based access control, least privilege, need to know, one user equal to one physical person, multi-factor authentication, backups, restore tests, recurring audit log analysis, conditional access policies, risk-based access policies, and managed-devices-only access are applied for relevant administrative and business-critical scenarios.

Confidentiality exposure is also minimized by product design because the add-on and Outlook add-in are self-hosted and customer-controlled, use no middleware or proxy servers, perform no external data processing, and do not phone home. Where support artifacts such as logs need to be exchanged, secure data exchange through a secure portal is used instead of email or public channels.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://set-outlooksignatures.com/outlookaddin, https://explicitconsulting.at/legal, https://explicitconsulting.at/support-terms

No, not as a built-in or preconfigured application component. Set-OutlookSignatures does not include built-in or preconfigured AI integrations such as generative AI, large language models, machine learning, or natural language processing.

AI may be used in the engineering process, but only for source-code-related assistance. AI may be used to assist with code reviews and code security analysis. This use is limited to source code only, not customer data. If AI is used, it is used to augment natural intelligence with artificial intelligence and never for vibe coding. No data of any kind is allowed to be used to train AI systems from this application context, except for information that has already been made publicly available, such as source code, issues, or documentation published on GitHub or on the website.

Customer data is not used to train AI. Set-OutlookSignatures is intentionally flexible and allows customers to integrate external data sources through scripting and custom logic. A customer could therefore choose to connect to external endpoints, including AI endpoints, as part of a customer-defined customization. That would be a customer-defined extension, not a built-in product AI feature.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/, https://set-outlooksignatures.com/features, https://set-outlooksignatures.com/help

No, not as a built-in or preconfigured application component. The add-on and its Outlook add-in do not include built-in or preconfigured AI integrations such as generative AI, large language models, machine learning, or natural language processing.

AI may be used in the engineering process, but only for source-code-related assistance. AI may be used to assist with code reviews and code security analysis. This use is limited to source code only, not customer data. If AI is used, it is used to augment natural intelligence with artificial intelligence and never for vibe coding. No data of any kind is allowed to be used to train AI systems from this application context, except for information that has already been made publicly available, such as source code, issues, or documentation published on GitHub or on the website.

Customer data is not used to train AI. Because the add-on builds on Set-OutlookSignatures, the same flexible configuration model applies: customers can integrate external data sources by scripting and custom logic. That could include AI endpoints if a customer explicitly chooses to wire them in. Such a configuration would be a customer-defined extension, not a built-in or preconfigured product AI feature.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://set-outlooksignatures.com/outlookaddin, https://explicitconsulting.at/services, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/

No built-in or preconfigured AI integration is provided in Set-OutlookSignatures. As a result, no customer data is sent to any AI service by default.

If a customer chooses to use the product’s flexible scripting and external data source capabilities to connect to an external AI endpoint, that integration is a customer-defined customization. In that case, the protection of customer data depends on the customer’s own configuration, governance, and the terms of the selected external AI provider, not on a built-in product AI feature.

In the engineering process, AI may be used only to assist with code reviews and code security analysis. This is limited to source code only, not customer data. No data of any kind is allowed to be used to train AI systems from this application context, except for information that has already been made publicly available, such as source code, issues, or documentation published on GitHub or on the website.

A separate AI product policy for Set-OutlookSignatures is not published in the reviewed public sources. Relevant public legal and project documentation can be found here: https://set-outlooksignatures.com/legal, https://set-outlooksignatures.com/, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/

No built-in or preconfigured AI integration is provided in the add-on or its Outlook add-in. As a result, no customer data is sent to any AI service by default.

If a customer chooses to use the flexible scripting and external data source capabilities inherited from the Set-OutlookSignatures ecosystem to connect to an external AI endpoint, that integration is a customer-defined customization. In that case, the protection of customer data depends on the customer’s own configuration, governance, and the terms of the selected external AI provider, not on a built-in add-on AI feature.

In the engineering process, AI may be used only to assist with code reviews and code security analysis. This is limited to source code only, not customer data. No data of any kind is allowed to be used to train AI systems from this application context, except for information that has already been made publicly available, such as source code, issues, or documentation published on GitHub or on the website.

A separate AI product policy for the add-on is not published in the reviewed public sources. The applicable public legal terms are available at https://explicitconsulting.at/legal.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://set-outlooksignatures.com/outlookaddin, https://explicitconsulting.at/legal, https://explicitconsulting.at/services

Yes, to the extent applicable to an open-source community project. Business-continuity risk is reduced primarily by product and distribution design. Set-OutlookSignatures is self-hosted, self-contained, and does not depend on a vendor-operated runtime service, external relay, or external data-processing platform for day-to-day operation in customer environments. Customers can therefore continue using the software in their own environment even if no interaction with the maintainers is possible.

Continuity is also supported through public source availability, versioned releases, and documented release history, so customers and the community are not dependent on a hidden proprietary runtime back end. Professional support is available separately, but it is not required for the software to keep functioning in a customer environment.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://explicitconsulting.at/support-terms

Yes. Business continuity procedures are maintained through an operating model that follows well-known service-management and information-security practices and frameworks, for example ITIL and ISO/IEC 27001-aligned controls. Continuity risk is additionally reduced by product design because the add-on and Outlook add-in are self-hosted and customer-controlled, perform no external data processing, use no middleware or proxy servers, and do not phone home. Customer operation is therefore not dependent on a vendor-run SaaS execution layer.

Continuity is also supported through controlled release management, professional support procedures, and professional software escrow for the proprietary component.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://set-outlooksignatures.com/outlookaddin, https://explicitconsulting.at/legal, https://explicitconsulting.at/support-terms

The impact of disruptions is reduced primarily by product design. Set-OutlookSignatures is self-hosted, self-contained, and does not depend on a vendor-operated runtime service, external relay, or external data-processing platform for day-to-day customer operation. A disruption on the maintainer side does not interrupt the customer’s productive use of the software in the customer’s own environment.

Disruption risk is also mitigated through public source availability, versioned releases, and documented release history, so customers and the community can continue to access the software and documentation without depending on a hidden proprietary back end. For security incidents or defects affecting the project, a published security policy defines responsible disclosure, investigation, patching, and communication commitments. Community support remains available through the project channels, and professional support can be obtained separately if needed.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/security, https://explicitconsulting.at/support-terms

Potential disruptions or incidents are addressed through an operating model that follows well-known service-management and information-security practices and frameworks, for example ITIL and ISO/IEC 27001-aligned controls, including structured handling of incidents, changes, releases, support, and recovery measures.

Disruption impact is also reduced by product design because the add-on and Outlook add-in are self-hosted and customer-controlled, use no middleware or proxy servers, perform no external data processing, and do not phone home. Customer operation is therefore not dependent on a vendor-run SaaS execution layer, and a disruption on the provider side does not stop productive use in the customer’s own environment.

Where support is needed during an incident, documented support channels, prioritized support for license holders, optional 24/7 and on-call support on request, and secure data exchange for log files through a secure portal are available. Professional software escrow for the proprietary component additionally supports long-term availability.

Relevant URLs: https://set-outlooksignatures.com/benefactorcircle, https://set-outlooksignatures.com/outlookaddin, https://explicitconsulting.at/legal, https://explicitconsulting.at/support-terms

Set-OutlookSignatures is an open-source community project, not a vendor-operated managed service. Professional support can be obtained separately, but the community project itself is not presented as a service organization that depends on subcontractors to operate customer environments. Because the product is self-hosted and customer-controlled, customer operation of the software does not rely on vendor-side third-party runtime providers.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/, https://explicitconsulting.at/support-terms

Yes, where appropriate. Where the provider cannot help well enough itself, selected partners may be used. At the same time, the add-on itself remains a product of the provider, and customer runtime operation remains self-hosted and customer-controlled rather than outsourced to a vendor-run SaaS platform.

Relevant URLs: https://explicitconsulting.at/services, https://set-outlooksignatures.com/benefactorcircle

For Set-OutlookSignatures, this is generally not applicable in the sense of a vendor-operated service chain. The project is an open-source community project, and the software is self-hosted and customer-controlled, so productive customer operation does not depend on vendor-side subcontractors or third-party runtime providers. If customers choose to obtain professional support separately, that is outside the core community project itself.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/, https://explicitconsulting.at/support-terms

Where selected partners are involved, security and reliability are ensured through careful partner selection, clear contractual expectations, and an operating model that follows well-known service-management and information-security practices and frameworks, for example ITIL and ISO/IEC 27001-aligned controls. Access is restricted according to role-based access control, least privilege, and need to know, and partner involvement is limited to what is actually required for the specific task. Multi-factor authentication, managed devices where relevant, and controlled handling of support and project artifacts are also used. Productive customer operation remains self-hosted and customer-controlled and therefore does not create a third-party SaaS runtime dependency.

Relevant URLs: https://explicitconsulting.at/services, https://set-outlooksignatures.com/benefactorcircle, https://set-outlooksignatures.com/outlookaddin

As an open-source community project, Set-OutlookSignatures does not claim a separate company-wide certification framework. It does, however, operate under the EUPL v1.2 licensing framework, maintain a published security policy for responsible disclosure and remediation, and design the project around digital sovereignty, least privilege, and need to know. The product is also publicly described as audit-ready and intended for use in security- and compliance-sensitive environments.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/license.txt, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/security, https://set-outlooksignatures.com/details#security-considerations, https://set-outlooksignatures.com/features

The organization complies with the applicable legal and contractual requirements governing its business and software delivery, including the legal framework published at https://explicitconsulting.at/legal. Its public company information also shows that it operates as an Austrian company within the UBIT section of the Austrian Economic Chamber.

For the purposes of this questionnaire response, the organization follows well-known service-management and information-security practices and frameworks, with ITIL and ISO/IEC 27001 as examples of the kinds of frameworks followed. This is consistent with the public positioning around governance, risk and compliance management, cloud and AI governance, and structured service and support delivery.

Relevant URLs: https://explicitconsulting.at/legal, https://explicitconsulting.at/services, https://explicitconsulting.at/support-terms

Compliance is supported primarily through product design, transparency, and documented controls. Set-OutlookSignatures is designed around digital sovereignty, least privilege, and need to know, and is publicly described as audit-ready. The full source code, the license, the changelog, the security policy, and versioned releases are published so the software and its changes remain reviewable and traceable.

Compliance is also supported through signed and hash-verifiable releases, controlled release management, documented permissions, and self-hosted operation with zero external data processing and no mail rerouting. This allows customers to assess and operate the software within their own compliance framework rather than relying on an opaque external service.

Relevant URLs: https://set-outlooksignatures.com/details#security-considerations, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/security

Compliance is supported through an operating model that follows well-known service-management and information-security practices and frameworks, with ITIL and ISO/IEC 27001 as examples of the kinds of frameworks followed, together with documented legal, contractual, operational, and technical controls. This includes structured handling of governance, risk and compliance, controlled engineering and release management, documented support processes, and secure handling of customer-related artifacts.

Compliance is also supported through product design. The add-on and Outlook add-in are self-hosted and customer-controlled, use no middleware or proxy servers, perform no external data processing, and do not phone home. Signed and hash-verifiable release artifacts, documented changes, secure support data exchange, and access-control principles such as role-based access control, least privilege, and need to know are also used.

Relevant URLs: https://explicitconsulting.at/legal, https://explicitconsulting.at/services, https://explicitconsulting.at/support-terms, https://set-outlooksignatures.com/benefactorcircle, https://set-outlooksignatures.com/outlookaddin

As an open-source community project, Set-OutlookSignatures does not operate as a commercial vendor organization with a conventional employee-based delivery model for the project itself. Formal employee security-awareness training is therefore not a defining control of the community project in the same way it would be for a commercial software provider. Secure project operation is instead supported through open review, published documentation, versioned releases, and a published security policy and responsible-disclosure process.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/security

Yes. Security-awareness and security-related training are provided to employees as part of an operating model that follows well-known service-management and information-security practices and frameworks, with ITIL and ISO/IEC 27001 as examples of the kinds of frameworks followed. This is consistent with the broader emphasis on governance, risk and compliance, structured service delivery, and controlled handling of customer and operational information.

Relevant URLs: https://explicitconsulting.at/services, https://explicitconsulting.at/legal, https://explicitconsulting.at/support-terms

As an open-source community project, Set-OutlookSignatures does not rely on a conventional employee-based operating model in the same way as a commercial software provider. Secure project practices are instead ensured through open review, peer review, public documentation, versioned releases, and a published security policy and responsible-disclosure process. These mechanisms make secure development and issue handling transparent and reviewable for maintainers, contributors, and users.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/security, https://set-outlooksignatures.com/features

Employees are kept knowledgeable about security best practices and adherence is reinforced through an operating model that follows well-known service-management and information-security practices and frameworks, with ITIL and ISO/IEC 27001 as examples of the kinds of frameworks followed, combined with security-awareness and security-related training, clear operational responsibilities, and access-control principles such as role-based access control, least privilege, and need to know. This is reinforced through technical and organizational controls such as one user equal to one physical person, multi-factor authentication, recurring audit log analysis, conditional access policies, risk-based access policies, and managed-devices-only access for relevant administrative and business-critical scenarios.

Relevant URLs: https://explicitconsulting.at/services, https://explicitconsulting.at/legal, https://explicitconsulting.at/support-terms

If a security incident affects the project, the published security policy applies. Private reporting is requested rather than public disclosure, receipt is acknowledged, the issue is investigated, impact is assessed, a fix or workaround is developed and released, and the outcome is communicated to users.

Versioned releases and documented release history are used so patches and mitigations can be distributed in a controlled and traceable way. Because Set-OutlookSignatures is self-hosted, does not rely on a vendor-operated runtime service, and is designed for zero external data processing and no mail rerouting, an incident on the maintainer side does not expose customer runtime data through a vendor SaaS processing layer.

Relevant URLs: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/security, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/releases, https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/blob/main/docs/CHANGELOG.md, https://set-outlooksignatures.com/features

If a security incident or data breach affects the organization, it is handled through an incident-management process that follows well-known service-management and information-security practices and frameworks, with ITIL and ISO/IEC 27001 as examples of the kinds of frameworks followed. This includes identification, containment, impact assessment, remediation, recovery, and communication.

Mitigation is supported with controlled engineering and release management, documented support procedures, and prioritized support for license holders, with 24/5 support on Austrian business days and optional 24/7 and on-call support on request where needed. Where customer-side troubleshooting is required, secure data exchange for logs is supported through a secure portal instead of email or public channels. Because the add-on and Outlook add-in are self-hosted and customer-controlled, use no middleware or proxy servers, perform no external data processing, and do not phone home, an incident on the provider side does not expose customer runtime data through a vendor SaaS processing layer.

Relevant URLs: https://explicitconsulting.at/legal, https://explicitconsulting.at/support-terms, https://set-outlooksignatures.com/benefactorcircle, https://set-outlooksignatures.com/outlookaddin