# Library security settings

Source: https://govform.com/resources/documentation/article/20-03-library-security-settings
Topic: Library Settings

Security settings place library-wide controls around Production deployment, Builder access and live operational data. Open the library, select **Library settings**, then **Security settings**. Only an authorised administrator should change these controls.

## Understand the controls

| Setting | What it controls | Operational consequence |
| --- | --- | --- |
| **Sandbox control** | Whether services in the library can be deployed to Production. | Sandbox mode prevents every Production deployment from this library. |
| **Enforce multifactor authentication** | Whether Builder users in the library must set up a second sign-in factor. | Affected users cannot access the library until setup is complete. External QA testers are not Builder users and are unaffected. |
| **Live data export** | Whether library users can download submitted live data as CSV or JSON. | An exported file leaves platform access control and audit coverage once it is on a local device. |
| **Disable User data view** | Hides the live user-data view in analytics for every service in the library. | Users following an existing link see guidance to contact an administrator. |
| **Disable Audit log view** | Hides the audit-log view in analytics. | Operational investigation may need another approved route. |
| **Allow Administrators to delete live records** | Enables record deletion from the user-data view for administrators. | Deletion becomes available only to that high-privilege role and should follow an approved retention process. |

## Use sandbox mode as a release guard

Choose **Sandbox mode – prevent Production deployments** for training, experimentation or a library that is not approved for live services. The control applies to the entire library, not just the current service.

Before allowing Production deployments, confirm that the library has named release owners, appropriate user roles, live integrations, data handling arrangements and a tested release process. Switching the guard off does not deploy anything by itself; it makes Production deployment possible for authorised users.

## Enforce multifactor authentication deliberately

Enabling the requirement can immediately block a Builder user who has not completed setup. Before applying it:

1.  Tell library users when enforcement will begin.
2.  Confirm that administrators have completed setup and recovery arrangements exist.
3.  Review pending invitations and accounts that are no longer needed.
4.  Apply the setting and verify access with a non-administrator Builder account.

The user-management list shows whether multifactor authentication is enabled for each user. An administrator can also reset a user’s setup from that user’s record when a legitimate recovery need is confirmed.

## Control live data access and export

The export control and the analytics-view controls solve different problems. Disabling export prevents supported CSV and JSON downloads; disabling the user-data view removes the interactive view. Consider them together with user roles, device controls, retention policy and external API access.

If export is allowed, define where files may be stored, how they are encrypted, how long they are retained and how an accidental disclosure is reported. Never use live exports in QA testing.

Allowing administrators to delete live records should be exceptional. Document who can authorise deletion, which evidence must be retained and whether another connected system also stores the record. Removing a record from one view may not remove copies held elsewhere.

## Apply and verify

Select **Apply** after reviewing every control on the page. Then verify the outcome that matters: attempt the restricted deployment, sign in as an affected role, open the relevant analytics view or test the approved export process. A saved checkbox is not evidence that the wider operating process is safe.

## Response Hub and live-record controls

| Setting | Behaviour |
| --- | --- |
| Response Hub (`responseHubEnabled`) | Enables the library's response workspace for permitted users. Missing/unset is disabled; enabling it does not grant a user a new access level. |
| Payment actions in Response Hub (`responseHubPaymentActions`) | `caseworkers` (default) allows people who can manage responses; `admins` restricts actions to administrators. Authorised viewers can still see payment details/history. |
| Allow Administrators to re-open live records (`enableAdminLiveDataReopen`) | Enabled unless explicitly set to false. Controls reopening from User data view; this is separate from returning a response for correction in Response Hub. |

Reopening changes the journey's state. It does not refund a payment. Use [payment casework](<https://govform.com/resources/documentation/article/payment-journey-and-casework>) for accepted unpaid responses and [Response review settings](<https://govform.com/resources/documentation/article/21-11-service-response-review>) for staff acceptance/corrections.

## Related guides

-   [Library user settings](<https://govform.com/resources/documentation/article/29-govforms-user-settings>)
-   [Library authentication settings](<https://govform.com/resources/documentation/article/20-04-library-authentication-settings>)
-   [Service environments and deployments](<https://govform.com/resources/documentation/article/21-09-service-environments-and-deployments>)
-   [Test, deploy and maintain a service](<https://govform.com/resources/documentation/article/13-test-deploy-and-maintain-a-service>)