Security and Reliability
At OpenGov, we treat the security and reliability of our cloud platform and that of the data it hosts with utmost importance. Building that level of trust with our customers is a key priority for us. Learn about our extensive security and reliability practices and comprehensive compliance controls on this page. Contact us at for additional information, reporting vulnerabilities, or any other concerns related to assurance of OpenGov’s cloud platform.
Security and Compliance:
A Shared Responsibility
OpenGov has structured the responsibility for security and compliance of its cloud platform such that it is shared between OpenGov, OpenGov’s Cloud Provider, and OpenGov’s customer. The sharing model leans heavily by design towards OpenGov and OpenGov’s Cloud Provider assuming most of the burden for secure operation of our platform, thereby greatly minimizing the concern vectors of our customers.
OpenGov uses infrastructure provided by the world’s leading Cloud Service Providers, and maintains strategic partnership with AWS, the industry-leading provider of cloud services. Note: for Security and reliability information related to Microsoft Azure, click here. OpenGov uses infrastructure provided by Amazon Web Services (AWS), the industry-leading provider of cloud services. AWS is responsible for protecting the infrastructure, which includes the hardware, software, networking, and facilities (data centers) that run AWS cloud services.
OpenGov uses a number of AWS cloud services such as EC2 and RDS for its applications. OpenGov has designed its security infrastructure and configuration using AWS-recommended security best practices. Additional security measures are taken for the OpenGov Citizen Services product suite as described here.
OpenGov’s customers are responsible for controls around Identity and Access Management to interface with OpenGov’s authentication frameworks, and appropriately analyzing and assessing the sensitivity of the data that is fed to the platform. (See this for additional information about OpenGov’s expectations on customer data.)
Physical and Environmental
The OpenGov Cloud platform is currently provisioned in the US East (Northern Virginia) Region of AWS. Within that Region, OpenGov uses multiple Availability Zones that are interconnected with each other using low latency, high-throughput, and highly-redundant networking. You can read more about AWS global infrastructure here.
OpenGov has purposefully built geo-isolation between its production and pre-production (e.g. dev/test) environments. Our pre-production environments are provisioned in the US West (Oregon) Region of AWS. OpenGov personnel do not have physical access to the data centers and as such OpenGov fully inherits the physical and environmental controls from AWS. You can read more about AWS’ data center controls here. Generally speaking, AWS infrastructure and cloud services are compliant with a number of industry-standard global frameworks such as CSA, ISO, and SOC and US frameworks such as NIST and FedRAMP. You can read more about AWS compliance programs here.
Monitoring and Alerting
OpenGov assures reliable operation of its platform and applications using a tightly-integrated suite of industry-standard monitoring and alerting services (e.g. for availability, performance, security, logging, and metrics). These services are supported by optimized processes and expert operational teams that are available 24x7.
OpenGov’s applications and infrastructure are designed to scale quickly and automatically in response to workloads, allowing us to provide steady and predictable performance to our customers. OpenGov can simply provision additional compute and storage based on the requirements of our customers.
OpenGov supports HTTPS using Transport Layer Security (TLS), an IETF standard cryptographic protocol, to provide end-to-end communications security for data that is fed to our platform. TLS is widely used for “encryption-in-transit” scenarios in internet communications and online transactions (e.g. by financial institutions).
Data stored in the OpenGov platform is encrypted “at rest” in the databases and storage using AES-256 (Advanced Encryption Standard with 256-bit keys). Use of AES is approved by NIST in its FIPS 197 publication.
OpenGov’s databases use multi-AZ deployment strategy to provide enhanced availability and durability. OpenGov performs regular backups of our entire database that are stored in multiple data-centers and in a back-up region. Our data is replicated in real-time to separate data-centers across AWS multi-availability zones, which allows us to switch to a replicated database immediately in the event of disaster or hardware fault, limiting data loss to a few seconds. In the rare event of data loss, OpenGov will restore from the last saved snapshot. Database snapshots are taken in the primary Region and transferred to an alternate Region on a regular cadence.
Application services are configured to run in isolated namespaces and containers on the cluster hosts with strict resource limits that prevent an unexpected or malicious activity in one service from affecting others. A minimum number of replicas of each service is deployed for high availability.
OpenGov uses Continuous Integration (CI) and an industry-leading vulnerability analysis service to continuously and automatically scan its applications for vulnerabilities at every stage of their lifecycle, especially during pre-production. All code repositories are continuously scanned for known defects and vulnerabilities, and they’re scanned again when that code is compiled into binary artifacts for distribution.
Additionally, OpenGov commissions an industry-leading independent third-party to conduct a penetration test of its applications and infrastructure. This test is conducted at least once a year.
An industry-leading Intrusion Detection Service (IDS) is in place for continuous monitoring across multiple concern vectors: vulnerability detection, file integrity monitoring, configuration auditing, and threat-correlation. A barebones, Linux-based operating system image is used on the hosts and is continuously monitored for vulnerabilities.
OpenGov uses a multi-tiered strategy for the protection of its cloud infrastructure. AWS Virtual Private Cloud (VPC) technology is used for isolation of compute instances and other resources. AWS Security Groups, a form of virtual firewall, are used for inbound and outbound traffic control. Protection against Distributed Denial of Service (DDoS) relies on AWS safeguards. Pre-production assets are protected using a VPN solution.
Remote access to OpenGov’s production cluster is strictly limited to OpenGov’s Engineering personnel. Each access request is approved by management on an as-needed basis, is fully audited, and granted for a limited time. Multi-Factor Authentication (MFA) is required for remote access. AWS IAM is used for fine-grained access.
Authentication and Authorization
OpenGov offers Single Sign-On (SSO) and platform-local authentication mechanisms to its customers. In the latter scenario, OpenGov uses the industry-standard BCrypt and PBKDF2 functions to “salt” and “hash” each password individually, storing it in an encrypted form, such that the original password cannot be derived, even if compromised. OpenGov uses Role-Based Access Control (RBAC) on its platform to authorize authenticated users to access and manipulate application data.
Service Maintenance and Upgrade
OpenGov platform updates (whether for hardware, software, performance, or scale) are hassle-free and transparent to our customers. We offer a high-level of predictability while at the same time providing a virtually continuous stream of new features and fixes.
Generally speaking OpenGov updates its applications every two weeks during off-business hours. The only times we make an exception to that is to deliver “hot fixes” for critical service issues. Regardless of the hour, our maintenance activities are performed without causing any downtime.
OpenGov applications use feature flags for controlled rollout of new features. Our releases are not monolithic in nature: we only deploy the set of services that need to change and can roll them back individually if needed. This allows us to isolate potential issues to a specific component of one application, and prevent it from affecting the update of other applications.
Our releases are performed using automated job pipelines and under the supervision of a group of “release managers” who are specifically trained to ensure a high-level of discipline in change management and risk mitigation.
Customers can subscribe to maintenance and incident notifications at our resource center, as outlined in, Keeping up with OpenGov.
OpenGov’s policies and procedures are based on NIST 800-53 recommended controls. All OpenGov personnel are required to go through a purpose-built information security and data privacy training upon joining and at least once yearly. Even though security is treated as a shared cross-functional responsibility, a dedicated operational team under the supervision of an Information System Security Officer oversees the entire security and compliance program at OpenGov.
OpenGov takes a comprehensive view on security and balances it with providing a first-rate solution to its customers by partnering with industry-leading vendors and solution providers. We hold our technology partners to high standards of security and carefully review their security practices and actively work with them to continuously improve the overall security of our platform.
OpenGov is an accredited technology partner in AWS Government Competency Program. This program recognizes OpenGov for its technical proficiency and proven customer success in delivering mission-critical workloads and applications to government customers on AWS. OpenGov undergoes an in-depth capability review, which is independently performed by AWS using its in-house expertise, every 12 months. Among other things, the review centers around OpenGov solution architecture (see AWS Well-Architected) and solution security (see AWS Security Best-Practices).