Security controls for Bullhorn contract workflows

Overview

RecruiterDocs is designed around role-based access, auditable contract actions, internal-only document preview, and fail-closed handling for integration endpoints. Production startup validation blocks deployment when required security settings are missing or misconfigured.

Need a DPA, sub-processor list, or deployment-specific detail? Email security@recruiterdocs.com.

Security highlights

• HTTPS/TLS in transit — the application is intended to run behind HTTPS. Production startup validation blocks deployment when SSL redirect or secure-cookie protections are disabled.
• Role-based access — admin and reporting areas are restricted to admin users. Contract artifacts are checked against a shared access policy.
• Auditability — contract, approval, and status actions are recorded so teams can review who sent, approved, rejected, or changed a contract flow.
• Internal-only preview and fail-closed machine endpoints — document preview stays inside the app. /contracts/api/v1/ requires bearer API tokens. DocuSign Connect rejects requests without a valid HMAC signature. The signatures webhook receiver rejects unknown or unconfigured providers.

1. Application access control

• Admin-only pages such as contract history, audit, and workspace settings are protected in the view layer.
• Contract downloads, previews, packs, audit reports, and support bundles are checked against a central version-access policy.
• Approval links are token-based with configurable expiry and usage limits. Tokens do not expose authenticated download links meant for internal users.

2. Data protection

• Production deployment runs behind HTTPS. Startup validation blocks production boot when SSL redirect or secure-cookie settings are disabled.
• Bullhorn iframe entry links can be HMAC-verified. In production, unsigned embed mode is blocked by startup validation.
• Document preview is generated internally as PDF by default. If a native Office viewer service is explicitly configured, Office files can be rendered through that service instead of the fallback PDF path.
• OAuth tokens, webhook signing secrets, and API credentials stored by the application are encrypted at rest using RD_ENCRYPTION_KEY.
• In production, startup validation blocks local filesystem document storage unless the operator explicitly acknowledges the risk. Object storage is the intended default for contract documents that may contain PII.
• Processing of personal data is governed by our Privacy Policy and, where applicable, a Data Processing Agreement (DPA) available on request.

3. Personal data and GDPR

• Candidate and client-contact personal data can appear in contract snapshots and related metadata, including fields such as name, email, phone, address, date of birth, NI number, and client contact details.
• Nightly retention purges can delete or scrub aged personal data using configurable command thresholds for snapshot retention and post-signature grace periods.
• GDPR Article 17 right-to-erasure requests are handled per placement. Personal-data fields are scrubbed from contract metadata and snapshots while non-personal structural data needed for audit continuity is retained.
• A DPA is available on request at security@recruiterdocs.com.

4. Authentication and integration security

• Current internal user access uses RecruiterDocs-managed accounts: admins invite users manually, users set a password from an emailed setup link, and password hashes use Django's standard authentication stack.
• Bullhorn OAuth authorizes Bullhorn data access and token refresh only. It does not authenticate users into RecruiterDocs.
• Email verification is tracked on the application user record as part of the current manual onboarding flow.
• Enterprise identity roadmap: SAML 2.0 SSO and SCIM 2.0 provisioning are planned. Okta and Microsoft Entra ID are the initial providers in scope for documented support. These identity features are not generally available today.
• API endpoints under /contracts/api/v1/ require a Bearer API token and reject invalid, expired, or wrong-workspace tokens.
• DocuSign Connect accepts POST requests only and rejects requests when the configured HMAC signature is missing or invalid.
• The generic signature-provider webhook endpoint under /webhooks/signatures/<provider>/ is fail-closed: unknown providers are rejected, and no provider is accepted unless verification and handler code are explicitly registered.

For the full integration surface — Bullhorn sync, signing, webhooks, and API tokens — see the integrations and technical overview.

5. Production hardening

• Startup validation blocks unsafe defaults such as DEBUG=True, a weak or default SECRET_KEY, empty or wildcard hosts, disabled SSL redirect, disabled secure cookies, SQLite, sandbox DocuSign URLs, or unsigned Bullhorn embed mode.
• Admin tooling and configuration screens are restricted to admin-capable users.
• Input validation and output encoding are used throughout the application to reduce common web-application risks.

6. Operational and deployment detail

Some operational controls depend on how RecruiterDocs is deployed. Hosting location, logging, backup frequency, restore procedures, and incident-handling commitments vary by deployment and are documented in the security pack available from the team.

7. Customer responsibilities

Security is a shared responsibility. To keep your data safe, we ask customers to:

• Use strong, unique passwords today and plan SSO rollout when the SAML roadmap items are available for your deployment.
• Keep user accounts up to date and promptly remove access for leavers.
• Configure internal permissions and approval flows appropriately for your agency.
• Ensure that the data you upload is collected and processed lawfully.
• Notify us promptly if you suspect unauthorised access to your account.

8. Questions and security contact

If you have security questions, need a copy of our DPA, or want more detail about specific controls:

Security email: security@recruiterdocs.com
General support: support@recruiterdocs.com