Compliance requirements can be complex—every company’s scope and responsibilities are unique.

This guide is here to help you confidently navigate the tests available on our platform, ensuring they align with your organization’s specific compliance needs. Whether you're acknowledging policies as an end user or building and implementing them as an admin, we’ll provide the guidance and answers you need to streamline the process and stay on track.

Below are some real world questions/answers from our customers to help you with specific guidance on some of our tests.

Organizational Controls

What roles should I have job descriptions for?

• To meet this requirement, an organization should define the roles and responsibilities for all existing, upcoming, and C-Suite roles.

What should the job descriptions include?

• A job description needs to include basic role requirements and expected responsibilities. Job descriptions should also be freely available to everyone at the organization. If this is not facilitated through an HR platform, we suggest creating a shared document (e.g., Google Docs) for existing roles and updating the document as new roles get added.
• When there are multiple individuals in the same role, a single job description is adequate. For example, if there are three senior software engineers within your organization, you'll only need one job description outlining the basic requirements and expected responsibilities of that position. 

How do I evidence the following control: "COMPANY maintains awareness of relevant applicable statutory, regulatory and contractual obligations"?

Auditors will be looking for a document (which can be MSWord or a spreadsheet) that your organization maintains outlining any statutory, regulatory, or contractual requirements it must adhere to and maintain.

• Statutory: Any obligations related to a statute, specifically an obligation to perform or refrain from performing an action as set out by state or federal law. Examples of statutory obligation come from rules of law, such as the Sarbanes-Oxley act or trademark protections. 
• Regulatory: Any obligation that comes from a government agency rule. Examples of regulatory obligations come from rules set by government agencies, such as OSHA or the EPA.
• Contractual: Any obligation related to a commitment made by the company via contract. An example would be if your organization has a contractual agreement to provide a SOC 2 report to certain customers.

Secureframe can provide a template, but customers must fill it out with their own obligations. Often these obligations are based on the state, country, continent or the industry that your company is in. For example, European data companies can be subject to GDPR, while American financial companies are often subject to FDIC or SEC regulations. This is especially important if those additional obligations affect your cybersecurity posture.

Frequently Asked Questions (FAQ)

I just ran across a new test called "File integrity monitoring". We are not a medical office/facility and we monitor system activity and have data encryption which is proven in other tests. Is this still relevant for us?

• In your case, this test can be disabled as long as the Encryption at rest/in transit and Monitoring for cloud/web tests are passing. 

I see there are a large set of "Physical Security Tests" in Secureframe, which previously pointed to a Policy, but are now upload tests. Why the change?

• Yes, that is correct, we recently changed this test from Policy to Upload. (see full list below of the test in question that were changed)
• Based on auditor feedback and continuous quality improvements to our frameworks, ultimately auditors want to verify, not only a physical security policy, but also the corresponding evidences for each of the physical security tests.
• Important note: For any of these new physical security tests if there is no physical environment in-scope, we would recommend marking these tests as not applicable stating AWS or the CSP is responsible for physical security controls.