Comment on page
Functions.store's Security and Change Management Procedures.
This document outlines some of Function Store's security practices and architecture.
We have a Data Protection Agreement (DPA) that can be requested and signed as a formal agreement between us and customers that require it. It outlines our obligations and procedures. It is reviewed once a quarter and updated as needed.
Our appointed Data Protection Officer is responsible for reviewing that it is up to date and its procedures are followed. Any customer can request a copy of the document by emailing
- Third-Party Connectivity
- Data Privacy
- Access Control
- Encryption Standards
We do not manage any physical servers or data centers. Our data is stored in Google Cloud Platform (GCP). Logs are maintained for access to data and stored in Cloud Logging. GCP was selected for our cloud provider due to its large foothold in the market.
We have separate GCP accounts for our development and production environments. The development environment is available to all of our engineers (with authentication) while the production environment requires separate logins.
Any engineer needing to connect to the production environment must request access with a reason and temporary permission will be allowed into the production environment.
When onboarding new employees, we follow the principle of least privileged access and manually provision only the necessary logins with the least amount of access possible to conduct their job. We explain what they have access to, why, and the valid use cases to use each service.
Changes to our environments are done via an automated continuous delivery system. Every change runs through a suite of thousands of unit, integration, and end-to-end tests. We do manual quality assurance, and our CTO code reviews and manually approves each outgoing deployment that goes to the production environment.
Our infrastructure is represented in code and updated through a version-controlled continuous deployment system. All changes are logged with the author, reviewer, and date-time.
When a security incident is detected, we immediately notify the entire engineering and management team and prioritize it as a High Priority (meaning once assigned, a responsible engineer drops whatever they're doing and immediately begins work on resolution).
The first step the responsible engineer takes is to determine the cause of the issue, a preliminary scope of impacted services and users, and the threat level. If one or more users are actively unable to use the service or at risk of secure information being leaked, then work continues and any other necessary parties are notified to help resolve the issue if needed.
Once the preliminary scope and severity have been assessed, a plan for containment and resolution is proposed, shared with the engineering team for any asynchronous feedback and work begins immediately. Our continuous integration & deployment system allows the responsible engineer to build, test and deploy their changes to test environments, and the CTO manually code reviews and approves all changes before they're sent to our production servers.
After resolution, a document is written with a brief overview, the cause of the issue, impacted services and users, duration of the event, how we resolved it, and steps being taken to prevent the issue from happening again. The document is shared with the user via the support email.