Discover how Actioner empowers teams across industries with streamlined workflows and task automation.
Stay updated with the latest insights
Explore step-by-step tutorials
Explore Actioner customers
Discover how Actioner stands out
Access a comprehensive knowledge base
Actioner applications and programming interfaces (APIs) are designed, developed, deployed, and tested in accordance with leading industry standards like OWASP and adhere to applicable legal, statutory, or regulatory compliance obligations. Our security development lifecycle takes into account compliance requirements and industry best practices.
Actioner uses both automated and manual analysis to detect security defects in the code prior to production. Our team of security engineers performs a rolling review of all source code for each of our products, applications, and codebases as part of our development cycle. Both automated and manual code reviews are employed. Actioner utilizes industry-recognized static code analysis tools in addition to an industry-standard software composition analysis tool to scan for vulnerabilities in third-party code/library dependencies.
We also utilize a mandatory dual peer review process, where multiple senior or lead developers review all commits to the default branch. Agile workflows let us identify and fix any vulnerabilities quickly, especially for our cloud services.
Actioner verifies that all of its software suppliers adhere to industry standards for Systems and Software Development Lifecycle (SDLC) security. Our legal and procurement teams review contracts, SLAs, and vendor internal policies to determine whether the vendor meets requirements for security, availability, and confidentiality. Review of those documents and deviations from standard requirements are documented and evaluated based on the type of service provided, as well as the future revisions and updates. Supplier contracts are reviewed annually.
We review our applications for security vulnerabilities to address any issues prior to deployment to the production.
Actioner customers retain the responsibility to ensure their use of our services is within compliance with applicable laws and regulations. All identified security, contractual, and regulatory requirements for customer access are contractually addressed and remediated prior to granting customers access to data, assets, and information systems. More details on our specific legal agreements and policies are available at https://actioner.com/terms-conditions and https://actioner.com/privacy-policy
As a general principle, Actioner uses frameworks that ensure the integrity of inputted / outputted data for our applications is as expected and conforms with the expected data classification of the communication. Data input and output integrity routines (i.e. MD5/SHA checksums) are implemented for application interfaces and databases to prevent manual or systematic processing errors or corruption of data.
Additional product features and behaviors that we introduced to empower the data security and integrity can be accessed on our Security Page.
Actioner develops and maintains an agreed-upon audit plan (e.g. scope, objective, frequency, resources, etc.) for reviewing the efficiency and effectiveness of implemented security controls. Our Actioner Compliance Team manages both our Internal Readiness audit schedule as well as our External audit schedule. All controls across our organization based on the risks of control failures are continuously monitored and evaluated.
Actioner uses a range of best-of-breed vulnerability detection tools that are run regularly across our applications and infrastructure to automatically scan for and identify vulnerabilities. This includes our cloud services, Docker application images, internal, mobile, and third-party applications, as well as our infrastructure. These tools automatically scan for and identify vulnerabilities that exist, and include:
Host-based scans: We currently use Amazon Inspector to perform continuous security scans of our internal and external perimeter. This tool is used to identify open ports, services, and applications running across our environment, as well as vulnerabilities on network hosts.
Container image scans: We use Docker containers for deploying all of our applications. We conduct a security scan of container images when they are deployed into our production or pre-production environments, using Snyk. More detail is provided later in this page.
Open source dependency scans: We use Snyk to identify vulnerabilities that may exist in open-source or third-party code dependencies. More detail is provided later in this paper.
AWS configuration monitoring: We use Trend Micro Cloud One - Conformity to provide continuous configuration monitoring against established baselines for our AWS environments.
Cloud stack monitoring: We use Resmo to discover unexpected configurations or settings in our AWS infrastructure, GitHub repositories, and a variety of cloud services that Actioner relies on.
We are continually reviewing the latest tools available and adding them to the suite we use if we believe they will enhance our vulnerability detection capabilities.
We also have a range of additional avenues that we use to identify vulnerabilities in combination with the automated scans we run. These include:
Customer & user reports: Users of our products can report any bugs they encounter at any time via support@actioner.com and our community channels. We will then work with them to collect all necessary details so the vulnerability can be flagged internally and fixed (subject to validation to ensure that the vulnerability is real, and not a false positive). This also includes Actioner staff, who can raise any issues they observe within our products (either externally, or internally) directly with the Security team, or by raising a support ticket.
External penetration testing: We use specialist security consulting firms to conduct white-box, code-assisted penetration tests on our product and infrastructure. Any findings from these tests are triaged and remediated according to our SLOs.
Our approach to penetration testing in these cases is highly targeted and focused. Such tests are generally be:
Actioner Security Team: We complete targeted code reviews, both manual and tools-assisted, and work closely with our product development teams to enhance their ability to self-detect and resolve vulnerabilities before the code reaches us. Another role of our security team is to simulate the role of adversaries attempting to identify and exploit vulnerabilities that exist within our systems, processes, and environments so that we can ensure they are identified and addressed as promptly as possible.
We use an internal ticketing and escalation system to track all vulnerabilities that we’ve discovered and aim to fix. Specifically, regardless of whether a vulnerability is identified through one of our scanning tools or one of the other avenues we have discussed above, a dedicated ticket is created for each vulnerability and is assigned to the relevant team for resolution. The remediation service-level objectives (SLOs) we have published in our Security Bug Fix Policy are tracked for each vulnerability.
Our security team provides oversight of this process and works with product and infrastructure teams to ensure the accuracy of vulnerabilities and answer remediation questions.
Once a fix for a vulnerability is developed, it is tested thoroughly and then incorporated into our CI/CD pipeline for deployment. Vulnerability tickets from scanning tools are automatically closed when subsequent re-scans do not find the vulnerability. Vulnerability tickets from manual findings are closed by product, infrastructure, or security team members when the fix has been made available to customers.
Container image scans
Actioner integrates an event-driven container security scanning process that monitors deployments made through our deployment platform (Typhon) for any containers that are deployed into our production environments. Additionally, developers are able to integrate a scanning process into our CI/CD pipeline for any containers that are deployed into our development environments. We use the Snyk Container engine for this purpose. Snyk provides a set of tools that undertakes a deep inspection of any container images that are deployed by our developers. This includes a detailed analysis of those images to identify the various components they contain and determine which have known vulnerabilities.
Open source dependencies
While it's important to find and fix vulnerabilities in our own code, our products and services also rely on numerous third-party libraries. It is therefore equally critical that we are aware of what libraries we're using and that they're up to date with the latest security bug fixes. We use a tool called Snyk to assist us with this. Snyk provides a scanner that can identify dependencies in any of our software builds and can then compare these libraries to a database of known security vulnerabilities.
Any identified vulnerabilities are then raised automatically via a formal ticket with the relevant product team in accordance with the vulnerability management process we described earlier on this page.
Actioner is a cloud-native product whose infrastructure is hosted on industry-leading cloud provider Amazon Web Services (AWS). Actioner cloud services and data are hosted on Amazon Web Services (AWS). Where all our computing, messaging, network, and storage layers are located in the US West, our browser application is distributed via our CDN network all over the world.
As a design standard, all Actioner services as well as the upstream computing, messaging, network and storage services are running on multiple availability zones (AZs) so that the traffic and the data are distributed among them. This design allows us to tolerate zone-specific failures with no downtime. This multi-zone high availability is the first line of defense for geographic and environmental risks and means that services running in multi-AZ deployments should be able to withstand AZ failure.
We operate a comprehensive backup program at Actioner. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our cloud services, and specifically referring to you and your application data, we also have extensive backup measures in place. Our data backups are retained for 30 days with support for point-in-time recovery and are encrypted using AES-256 encryption. Backup data is not stored offsite but is replicated to multiple data centers within a particular AWS region. We also perform quarterly testing of our backups. These backups are for operational constraints only, and we don’t use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted configurations.
On top of our cloud infrastructure, we’ve built a multi-tenanted microservice architecture with a shared platform that supports our services and applications. In a multi-tenant architecture, a single service serves multiple workspaces, including the storage services (e.g. AWS DynamoDB and AWS S3) and the instances of our computing power and to run our products (e.g.. AWS ECS and AWS Lambda). Each tenant’s data is isolated and inaccessible to other tenants and this is ensured via index and key designs of our storage services, as well as the network and application layers. It is important to note that we do not offer a single-tenant architecture.
Our microservices are built with the least privilege in mind and designed to minimize the scope of any zero-day exploitation and to reduce the likelihood of lateral movement within our cloud environment.
In Actioner, we are determined to build-in processes to plan for disruptions, and handle disruptions with minimal impact on our customers when they do occur. Our business continuity (BC) and disaster recovery (DR) programs capture the various activities done to meet those objectives.
Our BC and DR programs involve the following activities:
1. building-in redundancy measures to meet resiliency requirements
2. testing and verifying those redundancy measures
3. learning from tests to continuously keep improving BC and DR measures
We build our products to best utilize redundancy capabilities, such as availability zones and regions, offered by our cloud service providers.
We continuously monitor a wide range of metrics with the aim of detecting potential issues early. Based on those matrices:
Actioner has defined policies for formal authorization of new development and software purchase and acquisition. Development or acquisition of new applications, systems, databases, infrastructure, services, operations, and facilities is driven by management reviewed roadmaps.
Actioner relies on a Peer Review and Green Build (PRGB) control on all changes, whether the code, application, or infrastructure changes. Peer Review is configured in our delivery pipelines, where critical branches must be designated to have multiple reviewers for each Pull Request. Commonly this is two developers and a team lead. The Green Build portion of the control means that the integration during the build phase must pass all integration, functional, security, and other tests that have been developed. If these tests fail (a Red Build), the code will not be merged and must be reviewed again to address and fix the failures. Once a Green Build is successful, the binary is cryptographically signed and our production environment only runs binaries that are signed with our keys. Our testing process includes both automated and manual assessment components.
At Actioner, security is integrated into every phase of the development lifecycle to ensure that our code, products, and customers remain protected. We perform secure development practices across all the phases of the development life cycle.
At Actioner, there are only a few technical leaders that are authorized to install new software or to perform an infrastructural change on our production cloud environment. In most cases, software installation is not possible. We also utilize configuration management tools for our production environments to manage the configuration of all servers. Any direct changes made to those systems will be overwritten by the approved configuration ensuring consistency. We also rely on our Peer Review / Green Build (PRGB) controls to ensure multiple reviewers approve any changes.
All changes to the production system, including code or system configuration changes, require peer review prior to deployment to the production environment. Thousands of automated tests (including unit tests, integration tests, end-to-end tests, functional tests, etc.) are run against all production code prior to deployment, as well as regularly conducted automated vulnerability scans. All changes are tested in a staging environment prior to deployment to production. Production servers are managed via a centralized configuration system.
Protecting our customers' information and their user's privacy is extremely important to us. We are entrusted with some of our customer's most valuable data, which is why we have built security into every layer of the Actioner Cloud architecture. We provide replication, backup, disaster recovery planning, encryption in transit and at rest, advanced threat detection, common controls, and more.
As a company with a global customer base and operations, Actioner must be able to transfer and access data around the world. We understand and respect the rules for onward transfers of personal data outside of the European Economic Area (EEA), and offer customers a robust international data transfer framework. Our customers can lawfully transfer personal data to Actioner.
Whenever we share your data with Actioner service providers, we remain accountable to you for how it is used by any of these organizations. We require all service providers to undergo a thorough diligence process and enter into contracts that ensure our customers' personal data receives adequate protection and safeguards. We are aware that the European Data Protection Board recently issued further guidance on supplementary measures to meet the adequacy requirement of GDPR. We will continue to analyze these requirements and any others issued by European data protection authorities as they arise. In the meantime, please note that:
Actioner encrypts all data it processes in transit and at rest and maintains documented Key Management procedures for the cloud infrastructure. Encryption, key management, and decryption processes are managed via AWS Key Management Service (KMS), which is compliant with C5, ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC2, Fedramp, and AOC. The encryption, key management, and decryption process are inspected and verified internally by Amazon on a regular basis as part of their existing audit process. Actioner-managed keys are rotated upon relevant changes in roles or employment status.
Actioner uses industry-standard Transport Layer Security (TLS) version 1.2 to create a secure connection using 256 bit Advanced Encryption Standard (AES256) encryption. Servers holding user data will use full disk, industry-standard AES encryption. Tenant data is encrypted within AWS DynamoDB, AWS OpenSearch, and AWS Simple Storage Service (S3).
Actioner restricts, logs, and monitors access to our information security management systems. These restrictions include ACLs and multi-factor authentication requirements. We restrict, log, and monitor access to our Actioner Account Identity Store. Logs are stored in a logically separate system and write-access to the logs is restricted to the members of the Security Team. Any privileged access to these systems is logged within the application as well as AWS access. Alerts are sent to the Security Team when specific actions or events are identified within the logs.
Actioner applies a federated sign-in control that is integrated between our HR systems and our AWS infrastructure so that our internal access to AWS is also covered. As these processes are an established workflow, changes between our HR app and our internal systems are completed on an 8-hour sync.
Actioner ensures that only the right people can access your company’s information within the scope of a workspace. We support two types of authentication methods to Actioner for our end users, where both options are OAUTH 2.0 based and are constructed upon AWS Cognito, which is compliant with SOC, PCI, FedRAMP, and HIPAA. Actioner does not expect any passwords from users, hence does not store any user credentials.
Sign-In via Email: Every time a user attempts to log in due to an inactive session, Actioner sends an email with an authentication code to the user, that is one-time-usable and expires in 5 minutes. Expiration is enforced beginning from the storage layer. The session duration for a single client (browser) is 14 days.
Sign-In via Google: Every time a user attempts to log in due to an inactive session, Actioner redirects the user to the Google login page. The session duration for a single client (browser) is 14 days.
Our incident management process consists of the following steps:
Incidents can be detected in many ways including automated monitoring and customer reports.
When an incident occurs, the first step the team takes is creating an incident in Opsgenie. While the incident is getting created initially, the followings are the mandatory information that must be provided:
Detailed information is expected after creating the incident to start the process as fast as possible.
When the incident has been created but hasn’t been assigned to an Incident Commander (IC) yet, the incident is in an open state. This is the initial status of our incident workflow. Our automated flow ensures that whenever an incident is created, the followings are created and associated with the incident as well:
Based on the impacted services, the system automatically notifies the relevant on-call team(s) and the on-call responders are expected to join the Zoom within 5 minutes.
After the incident team's communication channels are set up, it's time to assess the incident so the team can decide what to tell people about it and who needs to fix it.
We have the following set of questions that ICs ask their teams:
The Incident commander is expected to assign a Scribe as fast as possible. The scribe is responsible to maintain a timeline of key events during an incident. Documenting actions, and keeping track of any follow-up items that will need to be addressed. It is important to capture a timeline of events as they happen so that they can be reviewed during the postmortem to determine how well we performed, and so we can accurately determine any additional impact that we might not have noticed at the time.
Regardless of the severity or impact of the incident, the incident commander ensures that the remediation process is started immediately.
The Incident commander is expected to assign a Liaison as fast as possible. A liaison is a person responsible for interacting with customers, either directly, or via our public communication channels. Generally, Liaison works with a member of the Customer Support team.
We use Statuspage for incident communications externally. The goal is to get communications up as quickly as possible.
After sending out initial communications, it’s crucial to keep the customers and the staff updated continuously. For external communications we simply update the incident that we opened on the external Statuspage earlier, transitioning its status as appropriate. We try to keep updates "short and sweet" because external customers aren't interested in the technical details of the incident - they just want to know if it's fixed yet and if not when it will be. Generally, 1-2 sentences will suffice.
Incident communication is an art, and the more practice you have, the better you'll be. In our incident manager training, we role-play a hypothetical incident, draft communications for it, and read them to the rest of the class. This is a good way to build this skill before doing it for real. It's also always a good idea to get someone else to review your communications as a "second opinion" before you send them.
An incident is resolved when the current or imminent business impact has ended. At that point, the emergency response ends, and the team transitions onto any cleanup tasks and the postmortem.
We send final internal and external communications when the incident is resolved. The internal communications have a recap of the incident's impact and duration, including how many support cases were raised and other important incident dimensions, and clearly state that the incident is resolved and there will be no further communications about it. The external communications are usually brief, telling customers that service has been restored and we will follow up with a postmortem.
For every incident, we need to follow up with a postmortem. A blame-free, detailed description of exactly what went wrong in order to cause the incident, along with a list of steps to take in order to prevent a similar incident from occurring again in the future. The incident response process itself should also be included.
The first step is designating a postmortem owner. This is done by the IC either at the end of a major incident call or very shortly after.
Once you've been designated as the owner of a postmortem, you should start creating one and updating it with all the relevant information. The postmortem process must be completed within the next 3 business days.
In Actioner, employee role changes and terminations are initiated only by the founders. The changes are then propagated through our systems automatically to deprovisioning where appropriate. We maintain an 8-hour sync between our HR systems and our internal identity store. Our team leaders have a checklist for employee exits to collect Actioner equipment and to validate that access is removed properly.
All Actioner staff globally are required to complete a background check if they've received an offer. A criminal check is run on all new hires and independent contractors - education verification, employment verification, or credit checks are added if the role or level of the position requires it. We perform full background checks for senior executive and accounting roles. Employees are required to acknowledge the Code of Conduct and reaffirm it on an annual basis, which includes security and privacy provisions.
Actioner provides information security training as an element of onboarding training for new hires, and on an ongoing basis to all staff. In addition to this general information security training, more targeted training is provided for our developers on secure coding and is supported through our embedded security engineers program. We also provide ongoing topical training related to malware, phishing, and other security concerns.
