GovDash Secure Configuration Guide

1. Purpose and scope

What this guide covers. This guide documents customer-configurable security settings in managed GovDash, including the recommended Team Admins configurations made through the GovDash web application. The configuration guidance in this article aligns with the requirements outlined in GovDash’s Customer Responsibility Matrix.

What this guide does not cover. Self-hosted deployments of GovDash components, dedicated single-tenant instances with contractual overrides, customer-side identity provider hardening (follow your IdP vendor's guidance), and external configuration of third-party SaaS integrations (SharePoint, Salesforce, GovWin, Okta, Microsoft Entra, Google Workspace). This guide references those integrations only as they connect to GovDash.

In GovDash, a top-level administrative account is any member who simultaneously holds Manage Team Members, Manage Team Roles, and Manage Team Authentication Methods. Other privileged accounts are defined in §3.1.

2. Shared responsibility at a glance

GovDash operates a shared responsibility model. Understanding who owns what prevents gaps.

GovDash is responsible for the security of the platform: application hardening, vulnerability management, underlying infrastructure on Azure Commercial, encryption of data in transit and at rest, logging of platform events, personnel screening, SDLC and change management, and continuous monitoring.

You (the customer) are responsible for the security in the platform: who you invite, what roles you assign, whether you enforce SSO, whether you enforce MFA, how you configure integrations, who holds privileged permissions, how you review activity logs, how you offboard departing staff, and what data you upload.

A condensed view of the division:

3. Identity and access management

Identity and access management is the highest-impact surface area you control in GovDash. This section defines who counts as a privileged user, lists the default roles, names the sensitive permissions, and gives concrete guidance on least privilege.

3.1 What counts as a privileged user

In GovDash, a privileged user is any Team Admin: any member who holds one or more of the following permissions:

• Manage Team Members (invite, remove, assign roles)
• Manage Team Roles (create, edit, delete roles)
• Manage Team Authentication Methods (SSO, MFA, allowed login methods)
• Edit Team Information (team details, Assistant settings, integration-adjacent fields such as GovWin and eBuy)
• Any Manage Settings permission in Capture Cloud, Contract Cloud, or Proposal Cloud
• Any Webhooks permission (Create / Edit)

These are the members who can change security controls or change information flow into or out of your GovDash tenant. Treat them as privileged accounts for your internal access reviews.

3.2 Default roles

GovDash ships a small set of default roles with preset permission limitations, plus the ability to create custom roles. The built-in defaults, which your Team Admin can rename or reshape under Settings → Roles → View and Edit Permissions, cover common patterns: full administrators, standard contributors, and a restricted "Word Assistant Only" role for users who should never see the main GovDash UI.

• Admin-tier default role. Full access to manage members, roles, integrations, authentication methods, and all Cloud-level settings.
• Standard contributor default role. Read/edit/create within the product Clouds but without administrative settings or member management.
• Word Assistant Only. A special role that restricts a user to the Microsoft Word add-in and uploading documents via the upload pane. Users in this role cannot log in to the main GovDash web application. Use this for reviewers or subject-matter contributors who should not have broader tenant access.

Verification note: the exact default role labels and preset permission values are controlled by the current GovDash application build. Before finalizing your role design, open Settings → Roles in your tenant to confirm the current defaults and adjust as needed.

3.3 Sensitive permissions and who should hold them

GovDash permission scoping is granular. The permissions listed below are the ones that change security controls or alter information flow to/from non-GovDash systems. Grant them sparingly and record each holder in your access review.

Permissions that change security controls:

• Manage Team Authentication Methods — turns SSO/MFA on and off, changes allowed login methods. Limit to 2–3 named administrators.
• Manage Team Roles — reshapes what every other role can do. Limit to the same 2–3 administrators.
• Manage Team Members — invites, removes, and re-roles members. Separate from the roles permission where practical so that role design and role assignment require two different people.

Permissions that change information flow with external systems:

• Edit Team Information — touches integration-adjacent settings (GovWin, eBuy, Assistant).
• Manage Settings in Capture Cloud — includes Salesforce connections. Anyone holding this can establish or remove a bidirectional sync between your GovDash opportunities and a Salesforce org.
• Webhooks (Read / Edit / Create) — webhooks push opportunity events to any external system you configure (commonly Salesforce). Whoever holds Create or Edit can send your opportunity data outside GovDash.
• Export in Capture Cloud — allows exporting the Capture Cloud Pipeline.
• Integration setup flows for SharePoint, Microsoft Entra SSO, Okta SSO, Google SSO, and GovWin require a user with both GovDash admin-level access and administrator-level access in the external tenant.

Permissions that expose sensitive business data:

• Read / Edit Sensitive Details in Contract Cloud — controls visibility of award value, total contract value, and CLINs.
• Delete permissions across Capture Cloud, Contract Cloud, Data Library, Proposal Cloud, Reports, Outline, Assistant, and Document Tags present data loss risk; grant only to trusted roles.

Guidance: No single user outside your named Team Admins should hold Manage Team Authentication Methods, Manage Team Roles, Manage Team Members, or Webhooks Create/Edit simultaneously. Access should be scoped to the smallest permission set that lets a user complete required functions in the application.

3.4 Account lifecycle

Provisioning. Team Admins invite new members through Settings → Members → Invite by entering the user's email address and selecting a role. Invitations are sent to the email entered; that email must match the user's identity provider email if SSO is enabled. GovDash does not currently support SCIM / automated provisioning, so you must first create the user's GovDash account before they can sign in via SSO. Plan new-hire onboarding accordingly.

Role changes. Role assignments happen in Settings → Roles → Add member on the target role, or via member management. Changes take effect immediately. Role-design changes (what a role can do) propagate to every member assigned to that role.

Deprovisioning. Remove departing members promptly through Settings → Members. Because GovDash does not provide SCIM-based automatic deprovisioning, you must integrate GovDash offboarding into your HR/IT leaver process as a manual checklist item. For users who authenticate via SSO, disabling the IdP account stops future logins but does not by itself remove the user's GovDash team membership — remove the member from GovDash explicitly.

Periodic review. Review your member list, role assignments, and the holders of the sensitive permissions above at least quarterly.

3.5 Multi-entity considerations

If your organization operates multiple legal entities (subsidiaries, joint ventures, teaming partners) that use GovDash, review the current state of multi-entity / multi-team management under Settings before expanding. Treat each entity's GovDash team as a separate trust boundary: a user who is a member of more than one entity's GovDash team should be inventoried explicitly because they have cross-entity data visibility. Apply the same privileged-user count minimization to each entity.

Verification note: confirm the multi-entity feature behavior in your current GovDash tenant before drafting your multi-entity access policy. The multi-entity support article on support.govdash.com is the authoritative customer reference.

4. Authentication controls

4.1 Login methods

GovDash supports the following login methods, configurable by a Team Admin with Manage Team Authentication Methods under Settings → Authentication:

• GovDash Authentication — email one-time code or passkey. This is the default when a team is first provisioned.
• Microsoft Entra (365) SSO — federation with your Microsoft tenant, including GCC and GCC-High tenants.
• Okta SSO — federation with your Okta org.
• Google SSO — federation with your Google Workspace.

GovDash’s Customer Responsibility Matrix requires use of an external IdP for full compliance with FedRAMP Moderate controls. If your organization’s IdP is not supported, contact security@govdash.com for support.

Allowed Login Methods is enforced at the team level. Once SSO is fully operational, disable GovDash Authentication so users cannot bypass your identity provider. The setting lives in Settings → Team Settings → Allowed Login Methods.

4.2 Configuring SSO

Microsoft Entra. Have your Microsoft Entra administrator authenticate to GovDash first to grant tenant-level consent, then enter your Microsoft Tenant ID in Settings → Authentication. Invited users must have matching email addresses in Entra.

Okta. Coordinate with your Okta administrator to set up the connection in Settings → Authentication.

Google Workspace. Enter your organization's Google Workspace Primary Domain in Settings → Authentication when enabling Google login. Only users whose email accounts are managed by that Google Workspace domain will be allowed to sign in — personal Gmail accounts, and accounts from other Google Workspace domains, are rejected. Make sure the primary domain you enter matches the one administered in your Google Admin console; a mismatch will prevent your users from signing in.

After any SSO is verified. Uncheck GovDash Authentication in Allowed Login Methods.

Removing SSO. Re-enable GovDash Authentication in Allowed Login Methods before deleting the tenant binding, to avoid lockouts.

4.3 Multi-factor authentication

GovDash supports MFA. The strongest and recommended configuration is to enforce MFA at your identity provider (Entra Conditional Access, Okta MFA policies, Google Workspace 2SV enforcement) and route all GovDash logins through SSO so that the IdP's MFA applies uniformly. If you use GovDash Authentication as a login method, use passkeys where possible for phishing-resistant MFA; email OTP provides one factor and should be paired with strong email account controls.

MFA enforcement is controlled by the holder of Manage Team Authentication Methods. Treat changes to MFA as a change-controlled event.

4.4 Passwords and session management

GovDash does not support password authentication. Direct login to GovDash uses email one-time codes or passkeys through GovDash Authentication; all other logins go through your identity provider via SSO. If you need to enforce a password policy, complexity, rotation, lockout, reuse history, configure it through your IdP. Your IdP controls initial authentication and, for Microsoft Entra, single sign-out. GovDash controls its own session lifetime and inactivity timeout, and when that session expires users are sent back to your IdP to sign in again.

4.5 Authorized signature and team identity

Under Settings → Team Settings, Team Admins also set the organization's legal name, DBA, logo, and Authorized Signature, which GovDash inserts into generated proposals. Protect this in the same way you would any digital signature artifact: limit who can change it to the same small set of Team Admins who hold Manage Team Authentication Methods.

5. Audit logging and activity monitoring

5.1 What GovDash logs

GovDash logs login events, administrative actions, data modifications, and configuration changes with timestamps. Platform-level logs are retained centrally, monitored for anomalies, and support incident investigation.

5.2 What customers can see in-app

Your team's activity is visible inside GovDash through the Activity surface accessible via the clock icon in the top menu bar. Selecting View all activity shows the full history of actions your team has taken across GovDash, Word Assistant, and Dash. This surface is the primary customer-facing audit view.

5.3 Recommended review cadence

• Daily / on-demand: after any suspected phishing, lost device, or compromised credential report.
• Weekly: spot-check administrative actions (role changes, member additions/removals, integration connections, SSO/MFA setting changes).
• Monthly: reconcile the GovDash member list against your HR/IdP source of truth.
• Quarterly: review who holds each sensitive permission listed in §3.3 and document in your access review.

5.4 Deeper forensic data

If you need access to platform-level or infrastructure-level audit data beyond what the in-app Activity view exposes (for example, for an incident investigation), contact GovDash support.

6. Integrations and data flow to external systems

Integrations are the primary way information flows out of or into GovDash. Treat every integration decision as an information-flow decision.

6.1 Integrations currently supported

• Microsoft SharePoint / Microsoft 365 (including GCC and GCC-High) — file sync, upload, proposal export.
• Microsoft Word Assistant — add-in deployed through Microsoft 365 admin center.
• Microsoft Entra SSO / Okta SSO / Google SSO — authentication federation.
• Salesforce (Pipeline) — bidirectional sync via webhooks.
• GovWin IQ — opportunity import via GovWin Web Services API.
• GSA eBuy — direct opportunity integration.
• Dash Web Search — outbound web search from the AI assistant; toggleable under Settings → Assistant → Web Searching. Dash does not perform web search on chats marked as CUI, regardless of the team-level Web Searching setting.

6.2 Recommendations for restricting integration configuration

• Restrict Manage Settings in Capture Cloud, Edit Team Information, and Webhooks (Edit / Create) to the same small Team Admin group that manages authentication.
• For SharePoint, prefer the limited-scope setup path (PnP app, per-site grants via script) over the broad tenant-wide grant whenever your security posture requires data-minimization. Document which SharePoint sites GovDash can reach.
• For Salesforce, the connection uses OAuth on behalf of the configuring user. Use a dedicated Salesforce integration user (not an individual employee's account) so the binding survives personnel changes and stays in your access review.
• For GovWin, create a dedicated GovWin Web Services user for the integration. GovWin API passwords expire every six months with no notification; add a calendar reminder 30 days before expiry.
• Disable the Web Searching toggle for Dash if your data-handling policy prohibits outbound web queries. Note that CUI-marked chats are already excluded from web search.

6.3 API keys, tokens, and secrets

Where GovDash accepts external credentials (GovWin Client ID/Secret, Microsoft Tenant ID, Salesforce OAuth, Google Workspace domain), those credentials are stored inside your GovDash tenant. Treat them as sensitive: rotate when integration users change, rotate after any suspected compromise, and never share Client Secrets via email or chat.

6.4 Webhooks as outbound data flow

Webhooks push opportunity create/update/delete events to the URL you configure, commonly Salesforce. Sharing CUI and other controlled data is not supported for Webhooks. Because webhooks can carry structured opportunity content across organizational boundaries, treat webhook creation as a change-controlled event:

• Restrict Create Webhooks and Edit Webhooks to Team Admins.
• Require code review or a security reviewer before adding a new webhook destination.
• Periodically list configured webhooks and verify each destination is still sanctioned.

7. Data protection and export controls

7.1 Encryption

Data in transit to GovDash is protected by TLS 1.2 or higher, with HSTS on all web interactions. Data at rest in Azure Commercial is protected by platform-managed encryption. Key management is handled by GovDash; customers do not manage keys directly in the managed SaaS offering.

7.2 Data isolation and AI training

GovDash uses logical tenant separation and strict data access controls. Customer data is not used to train or tune AI models. Dash AI outputs are generated from models trained on public, non-sensitive federal sources only.

7.3 Export controls

Customer data export paths include:

• Proposal exports to Microsoft Word or SharePoint.
• Capture Cloud Pipeline export, gated by the Export in Capture Cloud permission.
• Webhook-driven outbound sync to configured systems such as Salesforce.
• Ad-hoc document downloads from Data Library and Contract Cloud.

Control guidance: Grant Export in Capture Cloud and Webhooks Create/Edit only to roles that genuinely need to move data off platform. Use the Activity view to detect unexpected exports. For CUI, configure the GovDash information-tagging features (where enabled in your tenant) so that sensitive records are visually and functionally flagged on export.

7.4 Deletion and data lifecycle

Members with Delete permissions in each Cloud can remove records. Merging and deletion operations on contracts and companies are powerful and irreversible in the sense that relationships are re-pointed, not rolled back. Reserve Delete permissions for administrator-tier roles and include deletion events in your weekly audit review.

8. Configuration baseline checklist

Use this checklist at initial tenant setup and at each quarterly access review.

Privileged access

• No more than 2–3 named individuals hold the admin-tier role with Manage Team Members, Manage Team Roles, and Manage Team Authentication Methods simultaneously.
• Every Team Admin is documented in our internal access register with justification.
• A non-admin role with least-privilege has been defined for standard users, and the majority of members are in it.
• Word Assistant Only role is used for reviewers who do not need the main web app.

Authentication

• SSO is configured (Microsoft Entra, Okta, or Google) and tested end to end.
• For Google SSO, the configured Google Workspace Primary Domain matches the domain administered in Google Admin console.
• Allowed Login Methods excludes GovDash Authentication once SSO is verified.
• MFA is enforced at the identity provider for every user who can reach GovDash.
• Identity-provider session lifetime and re-auth policies are set per your internal policy.

Integrations and data flow

• Each connected integration (SharePoint, Salesforce, GovWin, eBuy, Word add-in) is sanctioned and documented.
• SharePoint uses limited-scope site grants where data-minimization is required.
• Salesforce and GovWin integrations use dedicated integration user accounts, not personal accounts.
• Every configured webhook destination is inventoried and owner-approved.
• GovWin API credential rotation is on a calendar reminder (every 6 months).
• Dash Web Searching toggle is set in accordance with your data-handling policy.

Data protection

• Export in Capture Cloud is restricted to roles that need it.
• Sensitive contract details (award value, CLINs) are restricted via the sensitive-details permissions.
• CUI is tagged where the tagging feature is enabled.

Monitoring and review

• Someone is assigned to review the Activity view weekly.
• Member list is reconciled monthly against HR/IdP source of truth.
• A quarterly access review of the sensitive permissions in §3.3 is scheduled.
• Offboarding checklist includes "remove from GovDash team" as an explicit step.

9. Obtaining, maintaining, and referencing this guide

Where this guide lives. The current version of this Secure Configuration Guide is published on support.govdash.com.

How we maintain it. GovDash updates this guide when the platform introduces or changes a customer-configurable security control, at least annually. Major changes are noted in a revision history at the bottom of the published article.

How to request additional documentation. Customers can request additional security documentation by emailing support@govdash.com or contacting their GovDash account manager.

How to give us feedback. If something in this guide is wrong, missing, or out of date against what you see in the product, tell us.

10. References

FedRAMP

• FedRAMP Rev 5 Secure Configuration Guide requirements — https://www.fedramp.gov/docs/rev5/balance/secure-configuration-guide/

GovDash customer documentation

• Roles & Permissions — https://support.govdash.com/docs/roles-permissions
• Adding new members — https://support.govdash.com/docs/adding-new-members-to-your-govdash-team-1
• Multi-entity management — https://support.govdash.com/docs/multi-entity-management
• Microsoft Entra / 365 SSO setup — https://support.govdash.com/docs/microsoft-entra365-single-sign-on-sso-setup
• Microsoft SharePoint integration setup — https://support.govdash.com/docs/microsoft-sharepoint-integration-setup
• Salesforce Pipeline integration setup — https://support.govdash.com/docs/salesforce-pipeline-integration-setup
• Webhooks — https://support.govdash.com/docs/webhooks
• GovWin integration — https://support.govdash.com/docs/govwin-integration
• GovDash Help Center — https://support.govdash.com/

This Secure Configuration Guide is maintained by Realize, Inc. and is intended for GovDash customers configuring the managed GovDash SaaS offering. For self-hosted or dedicated deployments, contact your GovDash account team for the applicable configuration documentation.

SCG-CSO-RSC
This guide is published in satisfaction of FedRAMP Rev 5 requirement SCG-CSO-RSC, which directs cloud service providers to create, maintain, and make available recommendations for securely configuring their cloud services. Per that requirement, this guide includes:

• (Required) Instructions on how to securely access, configure, operate, and decommission top-level administrative accounts that control enterprise access to the entire GovDash offering — see §3 (Identity and access management) and §4 (Authentication controls).
• (Required) Explanations of security-related settings that can be operated only by top-level administrative accounts, together with their security implications — see §3.3 (Sensitive permissions) and §4.1–4.3 (Login methods, SSO, MFA).
• (Recommended) Explanations of security-related settings operable by other privileged accounts and their security implications — see §3.3, §6 (Integrations), and §7 (Data protection and export controls).