The new Controls page allows you to view your security stance through the lens of controls and map them against our existing tests and framework requirements. You are also able to export structured CSVs and Evidence folders that allow you to track progress or work with your Customer Success Manager to get you ready for audit.

With the Controls page you can:

• Map Controls to Framework Requirements
• Map Tests to Controls
• Mark a Control as N/A
• Create Custom Tests in the Control Details View
• Export Evidence

You can find the Controls page in the left side navbar of the Monitoring view:

Control Page Overview

Secureframe automatically calculates the health status of each control based on the status of associated tests. However, you also have the ability to manually override this status when needed, document justification, and optionally assign a maturity rating to the control.

Understanding Control Health

Each control is evaluated as part of one or more compliance frameworks (e.g., CCPA, PCI DSS ROC, ISO 27001). The health status is displayed based on the number and result of mapped tests:

• Healthy: All associated tests are passing
• At Risk: One or more tests are incomplete or potentially failing
• Unhealthy: Tests are failing or missing required implementation

You’ll see the number of passing tests out of the total mapped to the control under the Frameworks section.

Overriding Control Health Status

Admins can override the automatically calculated control status by clicking Edit control status. This allows you to manually select:

• Healthy
• At Risk
• Unhealthy

⚠️ Overriding a control’s health status will replace the auto-generated status, so use this feature when your internal assessment differs from the test outcomes (e.g., implementation is confirmed but automated test is still in progress).

A justification is required when overriding, so you can capture internal reasoning or context (e.g., "Manual review completed by internal compliance lead").

You can also restore the original status at any time to revert back to the system-calculated health.

Control Maturity

Control maturity can be selected from a dropdown (levels 1 to 5) to reflect how fully a control is developed and embedded into your environment. For example:

• Level 1: Initial / Ad hoc
• Level 3: Defined and consistently implemented
• Level 5: Optimized / Continuous improvement

This optional field is helpful for tracking progress over time or supporting internal audit and risk assessments.

Additional Control Metadata

Each control also includes:

• Control ID and Name
• Implementation Date
• Implementation Plan (optional notes)
• Owner Assignment
• Tags to help filter or categorize controls

These fields allow for robust documentation and help teams assign responsibility, track rollout, and provide audit-ready details.

Marking Controls as Not Applicable (N/A)

Secureframe provides the option to mark controls as Not Applicable (N/A) when they do not apply to your organization. This is useful in cases where your environment or operations make certain controls irrelevant—for example:

• Physical security controls for a fully remote workforce
• Firewall controls for companies relying solely on cloud-native network protections (like AWS Security Groups)
• Data center-related controls if you use only third-party cloud infrastructure

You can mark controls as N/A in two ways:

• Individually: Open the control, click the ellipsis (⋮), and select Mark as N/A
• In bulk: Use the checkboxes on the control list, select multiple controls, and click Mark as N/A at the bottom menu

Be sure to provide a justification when marking controls as N/A. This adds transparency for your auditors and stakeholders.

Navigating the Control Tabs

Each control in Secureframe includes several tabs that help your team understand its purpose, related evidence, and progress toward compliance. Here's a breakdown of what each tab offers:

1. Details

This is the primary overview of the control. It includes:

• Control ID and Name
• Control Description
• Associated Frameworks and Mapped Tests
• Status (auto-generated or overridden)
• Owner
• Implementation Date and Plan
• Maturity Level (1–5)
• Tags for organizing and filtering

Use this tab for quick insight into how the control is applied across frameworks and who is responsible for maintaining it.

2. Requirements

This tab outlines the specific framework requirements that this control helps fulfill.

• Each framework (e.g., SOC 2, ISO 27001) will have a mapped requirement text.
• Helps clarify why the control exists and which audit criteria it supports.

Use this tab during audits or internal reviews to map controls directly to evidence requirements.

3. Testing

This tab shows all automated and manual tests associated with the control.

• View test name, type (automated/manual), frequency, and status.
• Quickly see if the test is Passing, Failing, or Needs Review.
• Click into any test for more details or to take action (e.g., upload evidence, run test).

If no tests are passing, the control may show as "Unhealthy" unless overridden.

4. Comments

Use this tab to collaborate across your team by leaving notes, updates, or decisions related to the control.

• Helpful for documenting implementation context, audit prep notes, or clarifying changes to the control.
• Comments are time-stamped and show who posted them.

Frequently Asked Questions (FAQ)

Are there common controls used in the mappings?

• Yes, Secureframe uses common controls where applicable.

Is there a place to mark controls as reviewed or passed?

Control health statuses in Secureframe (e.g., Healthy, Unhealthy, At risk) are automatically determined by the state of the tests mapped to that control.

For example, if all associated tests are passing, the control will be marked Healthy (see example screenshot). However, admins have the ability to override this auto-generated status.

Override Details:

• You can manually set a control's status to Healthy, Unhealthy, or At risk by clicking “Edit control status.”
• A justification is required when overriding.
• You can also restore the original status to return to the system-calculated state.
• Overriding allows teams to reflect real-world context even if automation hasn’t caught up (e.g., control is implemented but test is still being configured).

Control Maturity:

In addition to status, you can optionally select a Control Maturity level (from 1 to 5) to document how developed or operationalized the control is.