Test Types

LowerPlane provides six test types to cover the full spectrum of compliance verification needs. Each type serves a distinct purpose and operates differently in terms of triggering, evaluation, and evidence collection.

​

Automated Tests

Automated tests are created and run by LowerPlane when you connect an integration. They require no manual configuration or intervention. How they work:

1. When an integration syncs, the Go worker processes the incoming data.
2. The worker evaluates the data against predefined compliance criteria.
3. Test results are recorded with full details of what was checked and any findings.
4. Results update automatically on every sync cycle.

Examples:

• “MFA is enabled for all Okta users” (triggered by Okta sync)
• “S3 buckets are not publicly accessible” (triggered by AWS sync)
• “Branch protection is enabled on main branch” (triggered by GitHub sync)
• “All devices have endpoint protection installed” (triggered by CrowdStrike sync)

Schedule: Automated tests run every time their source integration syncs. The frequency depends on your integration sync settings (hourly, daily, or weekly).

​

Scheduled Tests

Scheduled tests run on a recurring cadence that you define. They are useful for compliance checks that need to happen at regular intervals but are not tied to a specific integration. Available schedules: Examples:

• “Quarterly access review completed” (quarterly schedule)
• “Vulnerability scan executed this week” (weekly schedule)
• “Disaster recovery test performed” (annual schedule)

​

Manual Tests

Manual tests require a person to upload evidence or confirm that an action has been completed. These are used for controls that cannot be verified through automated data collection. How they work:

1. The test appears in the Pending state until someone takes action.
2. The assigned owner uploads evidence (a screenshot, document, or other artifact) or marks the test as complete with notes.
3. The test moves to Passing status once evidence is provided.
4. The test returns to Pending when its evidence expires or a new cycle begins.

Examples:

• “Physical access logs reviewed” (upload access log export)
• “Security incident response drill conducted” (upload drill report)
• “Visitor management policy enforced at office” (upload visitor log)

Completing a manual test:

​

Policy Tests

Policy tests automatically verify that a required compliance policy exists, has been approved, and is within its review period. What policy tests check:

• A policy matching the required type exists in the Policy Center
• The policy status is Approved or Active
• The policy has not passed its next review date
• The policy is linked to the appropriate frameworks

How they work: Policy tests are linked to specific policy templates. When a policy is created, approved, and published through the Policy Center, the corresponding policy test automatically passes. If the policy expires, is revoked, or does not exist, the test fails. Examples:

• “Information Security Policy is approved and current”
• “Acceptable Use Policy exists and is active”
• “Data Retention Policy has been reviewed within the last 12 months”

​

Document Tests

Document tests verify that a required document is present in the evidence vault and has not expired. What document tests check:

• A document of the specified type exists
• The document’s valid_until date has not passed
• The document is associated with the correct controls

Examples:

• “Penetration test report uploaded within the last 12 months”
• “SOC 2 Type II report from cloud provider is current”
• “Business continuity plan document is not expired”

Document tests are similar to manual tests but focus specifically on document currency. They automatically fail when a document’s validity period expires, prompting the owner to upload an updated version.

​

Custom Tests

Custom tests let you define your own pass/fail criteria for any compliance requirement that does not fit the other test types. When to use custom tests:

• Compliance requirements unique to your industry or organization
• Internal security standards beyond framework requirements
• Tests that evaluate conditions not covered by existing integrations
• Composite checks that combine multiple data points

Creating a custom test:

​

Choosing the Right Test Type