As the trend towards cloud technology increases in popularity, security becomes an important issue for many companies. Are you worried about security in the cloud? Are you confident that your data is secure?

On This Page:

Cloud Security

We understand that your data is essential to your business operations and to our own success. We use a multi-layered approach to secure your information, constantly monitoring and improving our processes, services and systems.

Secure Data Centers

Our cloud services are deployed on Amazon Web Services (AWS) infrastructure.
AWS provides us first class data centers that are designed and managed in alignment with security best practices and a variety of IT security standards, including SOC 1/SSAE 16/ISAE 3402 (formerly SAS 70), SOC 2, SOC 3, FISMA, DIACAP, FedRAMP, DOD CSM Levels 1-5, PCI DSS Level 1, ISO 27001, ITAR, FIPS 140-2, and MTCS Level 3.
All of our servers reside in a number of availability zones in AWS's Northern Virginia region (us-east-1).
All customer data, including backups and redundant servers, are located only in the Northern Virginia region. We do not replicate our servers across to other regions either within the United States or internationally.
We do not operate in AWS's GovCloud region.

Secure Data Storage

All our data at rest, including our databases, backups, read replicas and snapshots, are encrypted before stored.
Since we leverage Amazon's Relational Database Service (RDS), our employees have no direct access to the actual database servers, which is fully managed by AWS.

Secure Data Transfers

Connection to our environment is done via TLS cryptographic protocols, ensuring that our users have a secure connection from their browsers to our services.
Individual user sessions are properly identified and verified on each transaction using a unique token created at login.

Secure Network

Our servers are deployed in a secure Virtual Private Cloud (VPC) network divided in a public and a private subnet.
All server processing and data storage takes place in private subnets with no direct access to the Internet.
We also have strict firewall policies between the public and private subnets, making sure that traffic can flow only in specific directions, to and from specific ports, including strict firewall policies between the application application and database tiers.
All traffic flowing out from our VPC goes through NAT instances which protects internal IP addresses from external hosts.
We also make sure only a single bastion host can access our internal servers for management purposes. This bastion host has a completely different IP address than our public IP addresses.
Our servers receive daily security patches to make sure they remain secure from new exploits. Password access to our servers and remote root logins are both disabled.
All AWS API access is audited to a secure write-only storage.

Backups

Backups are encrypted and performed daily remaining available for up to 35 days.

Security Policies

We centralize all our EC2 security across accounts using standard IAM policies.
We implement fine-grained security controls and follow the principle of least privilege.
Multi-factor authentication enabled on our master AWS accounts and master credentials are locked away and are not used for routine operational tasks.

frevvo Live Forms Application Security and Governance

Frevvo Live Forms employs a multi-layered approach to security, access control and application governance.

Access and Authentication

Default security provider - password salt and hashing.
Security provider integration with/delegation to third-parties, including SAML/SSO.
Access may be monitored and revoked.
Password reset/recovery self-service.

Authorization

Design Time

Forms/Flows owned by designer with all access granting authority. Only the designer/owner may modify the form/flow design.
Flow administration may be granted to any other user/role to give full access to audit trail and ability to modify/abort running instances.
Access to a flow instance’s audit trail may be granted to all participants or a to a custom set of users/roles.
Only the designer/owner may deploy the form/flow to production. Best practice is to have a deployer account on production system that owns the form/flow.

End User/Run Time

The designer/owner of a form/flow may designate who may use the form/flow with options for:

public access (anyone including anonymous users)
private access (the designer/owner only)
public in tenant (authentication users logged into tenant only)
Custom set of users or roles only.

The designer/owner of a form/flow may designate separately who may view individual submissions or may edit individual submissions. Either of these access lists may contain specific sets of individual users or roles. Additionally, specific access to individual submissions can be dynamically determined from the form/flow content at the time of submission in order to provide very granular access to specific submissions to specific users/roles.

Encryption

All data and app access encrypted via SSL/TLS (encryption in motion).
All data at rest is encrypted (AES 256).
All passwords salted and hashed.

Accountability

All workflow activity logged to an audit trail with access controlled by the designer/owner.
All system access/authentication events logged.

Integration

Secure integration with third-party cloud services. Support for OAuth tokens and specification of service credentials at the tenant and service level where applicable.