Independent external penetration testing helps identify weaknesses in the application. Findings feed into remediation and platform improvement, complementing the security work carried out during development and release.
For a service-specific assessment, discuss the scope of testing, the information your assurance team needs and any additional testing of your own configuration or integrations. Bespoke assurance activity can be scoped within an Institutional engagement.
External assessment complements internal security and quality checks.
Remediation addresses findings and informs subsequent platform work.
Your service’s identity, integrations and data use shape its assurance requirements.
Add configurable bot protection to service journeys and supported sign-in flows. Service-level protection helps distinguish legitimate users from automated activity, while platform traffic controls provide a separate layer of visibility and protection.
Choose settings around the users and tasks your service supports. Test the challenge, retry and failure experience in QA, including keyboard and assistive-technology use, so protection fits the journey.
Enable protection for the service paths that require it.
Check the user experience when a challenge cannot be completed.
Review bot protection alongside authentication and operational monitoring.
Automated security tests and application scanning help identify problems as the platform develops. Dedicated security checks and an isolated test target support assessment of application behaviour without using customer submission data.
These checks complement functional QA and independent penetration testing. Findings can inform investigation, fixes and further testing before a platform change is promoted through the release process.
Security checks form part of platform development and assessment.
Isolated scanning keeps active test activity apart from live customer services.
Quality assurance checks the behaviour that users and integrations depend on.
Library-scoped API credentials grant access to selected operations. Endpoint permissions separate capabilities such as reading information, updating definitions and deploying services. Optional source-IP restrictions let you limit where a key can be used.
Signed-request authentication provides an additional supported access method. Give each integration its own key and owner, keep the secret in a secure store, and review permissions when the integration’s purpose changes.
Select only the endpoints the consuming system needs.
Configure permitted source addresses where the integration has known network locations.
Plan credential rotation and revoke keys that are no longer needed.
Platform changes move through build, QA and Production promotion. Release workflows identify the candidate version, verify release metadata and use the tested application version during promotion, helping make changes traceable.
Health checks and recorded release information support verification after deployment and the handling of a release problem. Your service definitions have their own version history and deployment controls, alongside this platform release process.
QA provides a stage for checking changes before live promotion.
Version identity helps connect a release with the candidate that was assessed.
Deployment verification and rollback information support operational recovery.
Report a suspected vulnerability to our team with a clear description and safe reproduction steps. Explain the affected feature, the behaviour you observed and why you believe it could create a security risk.
Use the initial contact to arrange an appropriate channel for sensitive details. Our incident process provides a route for assessing the report, investigating the issue and coordinating the response.
Include the affected service or feature and the approximate time of observation.
Use test information and a minimal example when describing the issue.
Keep credentials, personal information and customer files out of the initial contact.
Govform supports server-side validation, conditional journeys and controlled action execution. These features let your team check information, enforce service rules and decide when an integration or workflow step should run.
Design validation around the service’s business rules and test the complete path in QA. Useful error messages help people correct mistakes while service checks help protect the quality of information reaching your operational systems.
Check required information, formats and rules before a user completes the journey.
Test different roles and conditional paths, including invalid inputs.
Verify that downstream actions run at the intended stage.
