Our Security Story

At Allocadia, we take the processing of our customer’s data assets very seriously. This is why we have built a comprehensive information security and privacy management program, designed to defend our systems and the data assets we process.

Our security practices were designed to defend the marketing plan using the same calibre of security measures that banks use to defend cash, assets, people and systems.

Security is a big part of our customer commitment. Many of the world’s largest businesses have put their trust in Allocadia, and we hope yours will, too.

On this page, we invite you to learn about the two components to Allocadia’s approach to security: product and data security, and privacy compliance.

Third-party Security and Compliance Validation

Allocadia undergoes regular third party audits of the security and risk management postures and capabilities of its systems, processes, and processing environments. The following third party audit reports are available for review under NDA:

Allocadia Third Party Assurances

  • SSAE18 SOC 2 Type II – Security
  • Third Party Penetration Test
  • BitSight ISO 27001 Assessment
  • BitSight NIST Assessment

Data Center Third Party Assurances

  • SOC 2 – Security, Availability, & Confidentiality Report
  • ISO 9001 – Global Quality Standard
  • ISO 27001 – Security Management Controls
  • ISO 27017 – Cloud Specific Controls
  • ISO 27018 – Personal Data Protection
Product Security Overview
Read Datasheet
Privacy & Data Protection Overview
Read Datasheet
Allocadia Privacy Policy
Read Policy

Product Security

At Allocadia, safeguarding customer data assets is the most important thing we do. Our security, privacy, and resiliency assurance programs are comprehensive, mature, and responsive, and designed to exceed the requirements of our global enterprise customers. From our CISO to our leadership team to each individual employee, everyone at Allocadia is committed to the security and confidentiality of your data assets.

Application Security

User Authentication

Access to the Allocadia application requires that all users authenticate themselves using the business email address (provided to them by their organization) and a secret password known only to the user. For organizations with their own identity provider, users access the Allocadia application from their SSO dashboard via a SAML 2 integration (see below).

Identity Federation through SAML

The Allocadia application supports identity federation through SAML2, providing organizations with credential centralization management capabilities through an Identity Provider under the customer’s control. For organizations desiring maximum control over authentication security, Allocadia recommends SAML integration with the organization’s own IdP.

Password Policy

The Allocadia application prevents users from creating weak passwords by enforcing a strong password policy for all application accounts. Any passwords set by the user must contain three of the four-character classes (lowercase, uppercase, numbers, and symbols) and must have a minimum length of eight characters. Limited customization of these complexity parameters is available within the application to allow customers the option to align complexity enforcement across their toolsets. Passwords are never stored in plain text. Instead, a bcrypt salted hash is stored in the Allocadia database. Organizations that choose to integrate with their own identity provider can enforce stronger controls, including multi-factor authentication.

Secure Data Transfer

All upstream and downstream data transfer between the user’s machine and the application servers and services is done over an encrypted connection signified by the “https://” URL. The Allocadia application encryption is based on a 2048-bit SSL certificate and 256-bit encryption with only TLS v1.2+ protocols allowed with the “MEDIUM” and “HIGH” class of cipher suites (anonymous DH ciphers disabled). If a user tries to visit a non-encrypted (“http://”) URL, they are redirected to the “https://” equivalent to force the encrypted connection at all times.

Session Handling

The Allocadia application is configured by default to keep the user’s sessions private and secure. Once a user successfully authenticates to the Allocadia application, a session is established on the server. If no activity that requires a round-trip to the server occurs within 60 minutes, the user session expires. After such expiration, no further actions can be performed and the user will be redirected to the login page when they next attempt to perform an action. In addition to the session time-out, sessions are invalidated when a user closes their web browser, or if they explicitly log out of the application.

API Access

The Allocadia application has an Application Programming Interface (API) that is disabled by default and can only be enabled by Allocadia administrators under the customer’s written authority in service of a documented and approved integration project driven and owned by the customer organization. Once enabled, each API request must contain valid credentials; any API request sent without valid credentials is discarded.

Allocadia Application Cookie Management

Cookies used by the Allocadia application:

  • Secure Cookies: The Secure attribute is meant to keep cookie communication limited to encrypted transmission, directing browsers to use cookies only via secure and encrypted connections.
  • HttpOnly Cookies: The HttpOnly attribute directs browsers not to expose cookies through channels other than HTTPS requests.

Authorization

The Allocadia application was designed with role-based access controls with prescribed privilege levels for users to access marketing plans in part or in whole. These rules ensure that only explicitly assigned users have access to customer data assets. The authorization rules are centered around budgets and the users who have different levels of access privilege to them, i.e., users only have access to data which has been explicitly granted by the customer. Any actions taken inside the Allocadia application are automatically checked against existing access controls which defend the data assets; if the user’s account or role does not have access privileges, the data is unavailable until the user is granted such privileges by the customer.

Protection Against Web Application Vulnerabilities

The Allocadia application is protected by active in-line security technologies which programmatically defend against web application and processing stack vulnerabilities and defects. All code is assessed against SANS 25 and OWASP 10.

Audit Trail for Application Actions

Every event in the stack generates an event log as data assets are processed and/or their state is modified. An audit log is kept for all major actions performed by users within the Allocadia application. For each action, the audit log contains the user or service which performed the action, the process which generated the event log, and a time stamp synced to the logging service. Passwords are not logged. The audit log is only accessible to Allocadia administrators; no programmatic access is available, nor are internal operations logs shipped outside the secure environment.

Quality Assurance

Allocadia’s development and devops staff are regularly trained in the assembly, shipping, and governance of secure software processing stacks. In addition, to ensure regressions do not appear, a set of automated software test suites are maintained and run by the Allocadia’s Dev QA team. This test suite includes both positive tests (e.g., a user should be able to access this budget) and negative tests (e.g., a user should not be able to access this budget) and is run continuously with new code changes and commits. A three-step testing process is executed against all builds prior to production promotion: (i) a security QA analysis performed by a peer; (ii) a SAST scan with no issues rated “medium” or higher; and (iii) a stack vulnerability posture assessment performed by the internal security team of the daily build. The Allocadia application source code is held in a secured private Git source code repository. Only the members of the Allocadia development team have permission to retrieve and submit changes to the source code. All access to Git is encrypted, access-controlled, and subject to regular internal audit.

Network Security

Data Centers

The Allocadia application is hosted within Amazon Web Services (AWS). AWS is a secure and reliable Infrastructure-as-a-Service hosting platform. Allocadia customers benefit from the world-class security measures that AWS employs at its data centers, ranging from the physical security of the facilities to its network, hardware, host operating systems, and virtualization services. AWS maintains dozens of current security and assurance certifications for a variety of global and national security frameworks.

Firewall & Production Access Control

The hosting environment is fronted with a load balancer and network firewall configured in deny-all mode by default. The only inbound ports open to the Internet are TCP 80 and 443 for http and https communication with the web server, respectively. All requests to TCP 80 are redirected programmatically to TCP 443; unencrypted sessions are never allowed. The firewall and WAF rules are reviewed regularly and updated as threats and risks evolve.

Remote access to the Allocadia application processing environment can only be accomplished via an SSH controlled by four-factor authentication controls. SSH runs on a non-standard port to further obfuscate itself and blocks access from everywhere other than approved and secure Allocadia corporate locations. Password-based authentication is disabled, requiring multi-factor authentication.

Encryption & Key Management Program

Allocadia is committed to ensuring secrecy, privacy, and security through the managed use of encryption technologies for data in transport and at rest. Weak cipher suites and ciphers with known cryptographic vulnerabilities are prohibited, with all key sizes enforced at a minimum of 2048 bits. Signature algorithms must be SHA256 or stronger (or equivalent strength hashing algorithm). Keys, certificates, and other encrypting artefacts are managed under the formal Key Management Process, with all access to keys and cryptographic artefacts logged and alerted against.

Web Application Firewall

Allocadia deploys a web application firewall in front of the Allocadia application which protects the web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. The WAF’s ruleset aligns to and reports on OWASP 10 issues based on both standard and custom rulesets. The WAF is actively monitored, with alerts going to the security operations team in real-time for analysis and action.

Production Access Control & Management

The web application server and database server application processes run under non-root, low-privilege user accounts rather than the “root” account. The production database is run within the encrypted AWS RDS, adding additional security layers while abstracting access through security groups and the IAM service, minimizing attack surface and authentication service presentation. Authentication into the production environment requires a jumphost IP-locked to the Allocadia HQ external IP, an active VPN account, a unique SSH host cert, an active and valid MFA token, and a valid AWS admin account.

System Security Visibility & Reporting

Allocadia deploys and manages a SIEM and log aggregation and analysis platform to monitor the production environment for deviations from baseline behavior and detect security risks before they can activate and propagate. “High” and “Critical” alerts are reviewed and actioned immediately, while non-CVE “Medium” alerts are reviewed during the weekly security stand up meeting.

Standard Server Image

Allocadia uses a standard immutable server image in the hosting environment. The image is based on Amazon Linux and includes a strong security configuration by default. In addition, standard industry best practices are employed to harden this server image, including, but not limited to, the following:

  • Only the minimum required software packages are installed.
  • Password-based authentication is disabled, requiring key-based authentication with passphrases.
  • Web server and database server processes run under non-root, low-privilege accounts.
  • File permissions are restricted for files/folders containing database data files, log files, and any other files with sensitive data.

Patch Management

Allocadia updates its server images to apply the latest security and hotfixes for the operating system and application software. Patching is scheduled by issue criticality, with “Critical”, “High”, and “Medium” patches seeing fixes within industry-standard mitigation times. Occasionally a reboot is required, which is done during the scheduled maintenance window.

Platform Resiliency

Data Center Locations

Allocadia delivers the Allocadia application from AWS’ highly secure and resilient network, hardware, and processing infrastructure. Allocadia maintains both production and warm standby processing environments in each processing jurisdiction (Ireland/Frankfurt and NorCal/Virginia) in the event one region were to become unavailable. These standby environments are provisioned in separate availability zones from the production environments to ensure recoverability and continuity of service.

System Monitoring

Allocadia utilizes both internal and external monitoring solutions to check the health of its systems. When monitoring agents identify an anomalous event, appropriate security team members are notified in real-time via email, secure corporate chat, and SMS notifications.

Backup

Allocadia performs a full database backup every 30 minutes. These backups are subsequently archived off-site with AWS’s S3 file storage service for a minimum of three months. Daily backups are held for a minimum of one year. Backups can be retrieved and restored by Allocadia administrators when required.

Business Resiliency

Allocadia has a comprehensive business resiliency program, covering operational incident response, security incident response, disaster recovery, and business continuity. Plans are tested semi-annually, with full review and update cycles occurring annually. Allocadia has set the following objectives specifically for restoring the Allocadia application for customers in the event of a disaster:

  • Recovery time objective (RTO): 8 hours
  • Recovery point objective (RPO): 1 hour

Privacy & Data Protection

Allocadia has a robust and comprehensive privacy and data protection program. We provide all the necessary resources and information to help our customers validate their privacy and compliance requirements, and to show how Allocadia meets these requirements.

Our Privacy and Compliance team governs the privacy and data protection program and ensures its effectiveness. This team is led by Allocadia’s data protection officer and corporate counsel, and operationalized by the CISO.

The team handles:

  • Creating, updating, and maintaining our data privacy policies and procedures, which protect the data assets handled by Allocadia employees and partners.
  • Making sure Allocadia meets the data privacy commitments it has made to customers, partners, investors, and employees.
  • Handling third-party audits of our privacy policies, and ensuring that we remain in compliance with those policies.
  • Providing data privacy and compliance training for employees.

Data Privacy

When considering Allocadia’s data privacy commitments, it is important to note that the Allocadia application is a business tool for marketing teams, and that:

  • The Allocadia application is not a data source for financial reporting purposes.
  • Although the Allocadia application can import financial data from finance systems, it only uses such data to help the marketing team become more efficient in their planning and decision making. There are no secondary uses for this data.
  • This data import function of the Allocadia application is not a two-way sync, nor is it a direct API connection to finance systems. The Allocadia application merely imports data from a flat file, which itself is exported by finance systems under controls operated by the customer’s systems administrator.
  • The Allocadia application does not and cannot manipulate financial data stored in a customer’s financial system of record.
  • The Allocadia application only processes a limited and predefined set of data assets as defined in the applicable data processing agreement. Such processing does not and will not include any data assets of any other third parties.

EU Data Privacy Requirements

Allocadia fully complies with all relevant data privacy requirements under EU General Data Protection Regulation (GDPR) regulations.

Specifically, we:

  • Meet all requirements under GDPR Chapter 3 (Rights of the Data Subject).
  • Have a fully compliant data processing agreement, standard contractual clauses, and appendices A, B, and C to the clauses.
  • Process privacy-impacted assets only in covered jurisdictions.
  • Have appointed a data protection officer and data privacy operations director.
  • Conduct employee training on compliant security and privacy procedures.
  • Publish Privacy Policies and Notices to inform customers of Allocadia’s compliance capacities and posture.
  • Provide configurable privacy and compliance features to our customers.
  • Carry out Privacy Impact Assessments.
  • Assure adequate data asset transfer methods for our customers.
  • Maintain records of data processing activities.
  • Assure that data processing agreement requirements with sub-processors are met.

Data Transparency

Allocadia provides transparency into the geographical regions where our customers’ data assets are stored and processed. The customer has its choice of processing jurisdictions to ensure compliance with relevant regulations. Allocadia, its customers, and its supply chain comply with applicable international data privacy regulations. Common privacy principles throughout jurisdictions include notice, choice, access, use, disclosure, and security. Our application is designed to only allow processing according to the customers privacy criteria, so organizations can meet the requirements of their country’s specific privacy laws.

Data Jurisdiction

Customers retain control over which privacy jurisdiction their data assets are processed and stored in. Data processing jurisdictional requirements are detailed in the Data Processing Agreement.

Allocadia operates two separate data processing environments in two separate processing jurisdictions: Northern California (with a backup processing site in Virginia) and Ireland (with backup processing site in Frankfurt, Germany). When a customer organization is first set up in the Allocadia application, we assign them to the processing jurisdiction of their choice (either EU or US). Once selected, all processing for that organization will occur within that jurisdiction.

Allocadia minimizes both the collection and use of personally identifiable data assets. For each user, our application only requires a business email address, and a first name and last name for identification/authentication purposes. These data assets are only used to authenticate and communicate with the user. There are no secondary or downstream uses of these personally identifiable data assets.

The table below shows which data assets the Allocadia application requires, how the data is processed and stored, who has access to it, and whether it travels across jurisdictions:

Data Asset Purpose Security Comments
User’s business email address
(mandatory)

Used by the application:

  • as the ‘username’ for the User.
  • to communicate with the user for application. events (password change prompt, ‘report is ready’ email notification).

Used by Allocadia Customer Success & Support:

  • to contact users for ongoing application support aligned to the written processing instructions provided by Users’ organization.
  • no usage of this Data Asset by any other function.

This asset is encrypted in transport (TLS 1.2) and at-rest (AES 256).

This data asset is only used to authenticate and support the user directly.

There are no secondary uses for this data asset.

This asset does not travel across processing jurisdictions.

User’s first and last names
(mandatory)

Used by the application:

  • to personalize the User experience.

Used by Allocadia Customer Success & Support:

  • to personalize the Customer Success and Support experience.
  • no usage of this Data Asset by any other function.

These assets are encrypted in transport (TLS 1.2) and at-rest (AES 256).

These data assets are used to personalize the user experience. Such assets are only processed in systems under Allocadia’s administrative control according to the written processing instructions.

There are no secondary uses for this data asset.

This asset does not travel across processing jurisdictions.

User’s job title / role
(optional)

Used by the application:

  • to personalize the User experience.

Used by Allocadia Customer Success & Support:

  • no usage of this Data Asset by the Success & Support teams.
  • no usage of this Data Asset by any other function.

This asset is encrypted in transport (TLS 1.2) and at-rest (AES 256).

This data asset is used to personalize the user experience. Such assets are only processed in systems under Allocadia’s administrative control according to the written processing instructions.

There are no secondary uses for this data asset.

This asset does not travel across processing jurisdictions.