This documentation is for frevvo v10.1. Not for you? Earlier documentation is available too.

Security and Governance

frevvo employs a multi-layered approach to security, access control, and application governance. This broadly includes both application-level security features as well as security and policies applied to our cloud-based solution.

frevvo Application Security

Access and Authentication

  • Default security provider with password salt and hashing.

  • Security provider integration with/delegation to third parties, including SAML 2.0/SSO and LDAP/AD for centralized security.

  • Access may be monitored and revoked.

  • Password minimum length requirement and ability to set strength requirement per tenant.

Authorization

Design Time

  • Forms/Workflows are owned by a designer who can administer access. 

  • Workflow administration may be granted to any other user/role to give full access to the audit trail and the ability to modify/abort running instances.

  • Read-only access to a workflow instance’s audit trail may be granted to all participants or a to a custom set of users/roles.

  • Other users may be granted the publisher role allowing them to administer form/workflow access and deploy to production.

  • Only the designer/owner or publisher may deploy the form/workflow to production.

End-User/Run Time

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

    • Anyone (login not required)

    • Authenticated Users (login required)

    • Designer/Owner Only

    • Custom set of users or roles only

  • The designer/owner of a form/workflow may designate user(s)/role(s) who may view individual submissions or may edit individual submissions.

Encryption

  • All data and app access are encrypted via TLS (encryption in motion).

  • All data at rest is encrypted (AES 256).

  • All passwords salted and hashed.

Accountability

  • All workflow activity is 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.


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/ISAE 3402, SOC 2, SOC 3, FISMA, DIACAP, FedRAMP, PCI DSS Level 1, ISO 9001, ISO 27001, ISO 27017, ISO 27018.
  • Production servers reside in a number of availability zones in AWS's Northern Virginia region (us-east-1).
  • Backups and redundant servers are located in AWS's Oregon region (us-west-2) for disaster recovery purposes.
  • We do not replicate our servers 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 are 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 uniquely 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 into 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 between the application and database tiers.
  • All traffic flowing out from our VPC goes through NAT instances which protect internal IP addresses from external hosts.
  • Access to internal servers is logged and managed by AWS Systems Manager/Session Manager, and sessions are encrypted using AWS Key Management Service (KMS).
  • Our servers receive daily security patches to make sure they remain secure from new exploits.

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 principles of least privilege and need to know.
  • Multi-factor authentication is required for all AWS account access.