How Can I Prove My Role-Based Access Control (CC6.1) Works Using Automated Evidence Capture?

Document RBAC effectiveness by automatically capturing: 1) User permission matrices, 2) Login attempts with different roles, 3) Access denial screenshots, 4) Audit logs showing blocked attempts. Schedule these captures quarterly to maintain continuous compliance evidence for SOC 2 CC6.1.

---

What is CC6.1 and Why Do Auditors Care?

CC6.1 Definition

Trust Service Criteria CC6.1 (Logical and Physical Access Controls) requires:

"The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives."

In plain English: You must prove that users can only access data and features appropriate for their role.

Why This Control is Critical

CC6.1 is a foundational control that auditors scrutinize heavily because:

1. Prevents unauthorized access to sensitive customer data
2. Limits blast radius of compromised accounts
3. Ensures separation of duties (developers can't approve their own changes)
4. Protects financial data and intellectual property

Auditor focus areas:

• Can a "Viewer" user access admin features?
• Can deleted/deactivated users still login?
• Are permissions enforced at the API level (not just UI)?
• Do audit logs capture access denial attempts?

What Evidence Auditors Require

Auditors need visual proof that RBAC works, not just policy documents:

Evidence Type	What Auditors Want to See	Format
Permission matrix	Which roles have which permissions	Screenshot of RBAC config
Access denial proof	Unauthorized users blocked from features	Screenshots of "Access Denied"
Audit logs	Failed access attempts logged	Screenshots of log entries
Role assignment process	How roles are assigned/revoked	Workflow documentation
Test results	Quarterly verification tests	Timestamped test reports

Key requirement: Evidence must be collected quarterly (for SOC 2 Type II) to prove controls are operating effectively over time.

---

The Manual Approach (What Most Teams Do)

Step-by-Step Manual Process

Quarterly task (every 3 months):

1. Create test users (30 minutes)

   • Create user with "Viewer" role
   • Create user with "Editor" role
   • Create user with "Admin" role

2. Perform access tests (60 minutes)

   • Login as each user
   • Attempt to access features beyond permissions
   • Take screenshot of each denial
   • Document expected vs actual behavior

3. Capture audit logs (20 minutes)

   • Open logging system
   • Search for access denial events
   • Screenshot relevant log entries
   • Verify timestamps match tests

4. Document results (45 minutes)

   • Write test report describing each step
   • Organize screenshots by role
   • Add timestamps and tester information
   • Note any discrepancies

5. Format for auditors (30 minutes)

   • Create PDF with all evidence
   • Add cover page with control ID
   • Include test methodology
   • Upload to Vanta/Drata

Total time per quarter: 3 hours Annual time: 12 hours Annual cost: $2,400 (at $200/hour compliance rate)

Problems with Manual Approach

❌ Time-intensive: 3 hours every quarter adds up to 12 hours/year

❌ Error-prone: Easy to forget steps or miss screenshots

❌ Inconsistent: Different tester = different documentation quality

❌ Not continuous: Tests only run quarterly, not ongoing

❌ Hard to scale: Adding more roles/features increases time exponentially

---

Automated RBAC Evidence Collection

What Gets Automated

✅ Screenshot capture during role-based testing ✅ Test script execution with multiple user roles ✅ Audit log extraction and formatting ✅ Evidence description generation via AI ✅ Report formatting for auditors ✅ Quarterly scheduling with reminders

How Automation Works

Phase 1: One-Time Setup (30 minutes)

1. Install browser extension (Screenata)
2. Define test cases for each role:

{
  "cc6_1_rbac_test": {
    "roles_to_test": [
      {
        "role_name": "Viewer",
        "test_user": "viewer@company.com",
        "should_not_access": [
          "/admin/users",
          "/admin/settings",
          "/api/customers/delete"
        ]
      },
      {
        "role_name": "Editor",
        "test_user": "editor@company.com",
        "should_not_access": [
          "/admin/billing",
          "/admin/users/delete",
          "/api/database/admin"
        ]
      }
    ],
    "expected_behavior": "Access denied with 403 error",
    "log_location": "CloudWatch Logs /var/log/application",
    "test_frequency": "quarterly"
  }
}

3. Connect to audit log system (CloudWatch, Datadog, Splunk)
4. Configure Vanta/Drata integration

Phase 2: Recording First Test (10 minutes)

1. Open application in Chrome
2. Click Screenata extension → "Start Recording" → "CC6.1 RBAC Test"
3. Login as "Viewer" role user
4. Attempt to access admin features
5. System automatically captures:
   • Login screen with role displayed
   • Navigation to restricted page
   • "Access Denied" error message
   • Browser DevTools showing 403 HTTP response
6. Navigate to audit log system
7. System captures log entry showing blocked attempt
8. Click "Stop Recording"

Phase 3: AI Evidence Generation (2 minutes)

AI automatically creates:

1. Test Report (PDF)

CC6.1 RBAC Access Control Test
Date: 2025-01-19 14:32 UTC
Tester: compliance@company.com
Environment: Production

Test Case 1: Viewer Role Access Restriction
User: viewer@company.com (Role: Viewer)
Action: Attempted to access /admin/users
Expected: Access denied with 403
Actual: Access denied with 403 ✓ PASS
Evidence: Screenshots 1-4, Audit log entry

[6 screenshots with AI-generated descriptions]
[Audit log screenshot with highlighted entry]

Test Result: PASS
RBAC enforcement verified for Viewer role.

2. Evidence Package

• CC6.1_RBAC_Test_2025-Q1.pdf (full report)
• /screenshots/ (12 timestamped images)
• audit_logs.json (extracted log data)
• metadata.csv (test details)

Phase 4: Export to GRC Platform (1 minute)

• Click "Export to Vanta"
• Evidence automatically links to CC6.1 control
• Control status updates to "Evidence Collected"

Total time per quarter: 13 minutes (10 min test + 2 min AI + 1 min export) Annual time: 52 minutes Annual cost: $273 (at $200/hour) + $1,788 (Screenata) Total: $2,061/year

Savings vs manual: $339/year (14% reduction) + improved consistency

---

Required Evidence Components for CC6.1

1. User Permission Matrix

What it shows: Which roles have access to which features

How to capture automatically:

// Screenata extracts RBAC config from your application
{
  "roles": {
    "Viewer": {
      "permissions": ["read:customers", "read:reports"],
      "ui_access": ["/dashboard", "/reports"],
      "api_access": ["GET /api/customers", "GET /api/reports"]
    },
    "Editor": {
      "permissions": ["read:customers", "write:customers", "read:reports"],
      "ui_access": ["/dashboard", "/reports", "/customers/edit"],
      "api_access": ["GET /api/customers", "POST /api/customers"]
    },
    "Admin": {
      "permissions": ["*"],
      "ui_access": ["/*"],
      "api_access": ["* /api/*"]
    }
  }
}

Evidence format: Screenshot of permissions table + JSON export

2. Access Denial Screenshots

Required screenshots per role:

Role	Test Scenario	Expected Screenshot
Viewer	Attempt to access /admin/users	"Access Denied" or 403 error
Viewer	Attempt to edit customer data	"Insufficient Permissions" message
Editor	Attempt to delete users	"Admin privileges required"
Editor	Attempt to access billing	403 error page

Automation captures:

• Before state (user logged in with role displayed)
• Action (clicking restricted feature)
• After state (denial message)
• Browser network tab (showing 403 HTTP response)

3. Audit Log Evidence

Required log fields:

{
  "timestamp": "2025-01-19T14:32:18Z",
  "event": "access_denied",
  "user": "viewer@company.com",
  "user_id": "usr_12345",
  "user_role": "Viewer",
  "requested_resource": "/admin/users",
  "http_method": "GET",
  "response_code": 403,
  "ip_address": "192.168.1.100",
  "user_agent": "Mozilla/5.0...",
  "session_id": "sess_abcd1234"
}

Screenshot requirements:

• Log entry showing access denial
• Timestamp matching test execution time
• User email and role visible
• Requested resource path shown

4. Test Methodology Documentation

Required documentation:

## CC6.1 RBAC Test Procedure

**Objective:** Verify that role-based access controls prevent unauthorized access to sensitive features.

**Test Frequency:** Quarterly

**Test Environment:** Production

**Roles Tested:**
- Viewer (read-only access)
- Editor (read/write access to customer data)
- Admin (full access)

**Test Steps:**
1. Login as Viewer user
2. Attempt to access /admin/users (should fail)
3. Verify 403 error displayed
4. Check audit log for denial entry
5. Repeat for Editor and Admin roles

**Pass Criteria:**
- Viewer cannot access admin features (403 error)
- Editor cannot delete users or access billing
- Admin has full access
- All attempts logged to audit system

**Test Date:** 2025-01-19
**Tester:** compliance@company.com
**Result:** PASS

---

Integration with Identity Providers

Okta Integration

What to capture:

• User role assignments in Okta
• Group memberships
• Application access policies

Automation approach:

// Screenata connects to Okta API
const oktaEvidence = {
  "user": "viewer@company.com",
  "groups": ["Viewers"],
  "app_assignments": {
    "YourApp": {
      "role": "Viewer",
      "assigned_date": "2024-06-15",
      "assigned_by": "admin@company.com"
    }
  }
}

Evidence includes:

• Screenshot of Okta user profile showing role
• Screenshot of group memberships
• API response with role data
• Audit log from Okta showing role assignment

Azure AD Integration

What to capture:

• Role assignments in Azure AD
• Conditional access policies
• Sign-in logs showing role enforcement

Automation approach:

# Screenata executes Azure AD query
Get-AzureADUser -ObjectId "viewer@company.com" |
  Select-Object UserPrincipalName, AssignedRoles

Evidence includes:

• Screenshot of Azure AD role assignments
• Conditional access policy screenshots
• Sign-in logs showing blocked access
• API response with role data

Custom RBAC Systems

What to capture:

• Database tables storing user roles
• Application code enforcing permissions
• API middleware checking roles

Automation approach:

-- Screenata captures database state
SELECT
  users.email,
  users.role,
  permissions.permission_name
FROM users
JOIN user_permissions ON users.id = user_permissions.user_id
JOIN permissions ON user_permissions.permission_id = permissions.id
WHERE users.email = 'viewer@company.com';

Evidence includes:

• Screenshot of database query results
• Screenshot of RBAC configuration UI
• Code snippet showing permission checks
• API endpoint documentation

---

Quarterly Testing Schedule

Q1 Testing (January - March)

Week 1:

• Review RBAC configuration changes since last quarter
• Update test cases if new roles added
• Verify test users still exist

Week 2:

• Execute automated RBAC tests
• Review AI-generated evidence
• Check for any failed tests

Week 3:

• Upload evidence to Vanta/Drata
• Mark CC6.1 control as tested
• Archive evidence locally

Week 4:

• Review with compliance team
• Address any audit findings
• Schedule Q2 tests

Setting Up Automated Reminders

Calendar integration:

{
  "quarterly_tests": [
    {
      "control": "CC6.1 RBAC",
      "frequency": "quarterly",
      "test_window": "first two weeks of quarter",
      "reminder_days_before": 7,
      "assignee": "compliance@company.com",
      "backup_assignee": "security@company.com"
    }
  ]
}

Slack notifications:

• 7 days before quarter end: "CC6.1 RBAC test due in 1 week"
• 3 days before quarter end: "CC6.1 RBAC test due in 3 days"
• On quarter end: "CC6.1 RBAC test overdue"

---

Advanced RBAC Testing Scenarios

Testing Dynamic Permissions

Scenario: Permissions change based on data ownership

Example: User can edit their own customers, but not others' customers

Test approach:

// Test case 1: Own customer access
{
  "user": "editor1@company.com",
  "action": "edit",
  "customer": "customer_owned_by_editor1",
  "expected": "success",
  "test_result": "PASS"
}

// Test case 2: Other's customer access
{
  "user": "editor1@company.com",
  "action": "edit",
  "customer": "customer_owned_by_editor2",
  "expected": "access_denied",
  "test_result": "PASS"
}

Evidence: Screenshot showing access denied when editing other user's customer

Testing API-Level Permissions

Scenario: UI might hide features, but API still accessible

Test approach:

1. Login as Viewer user
2. Open browser DevTools
3. Attempt direct API call to restricted endpoint:

   fetch('/api/admin/delete-user', {
     method: 'DELETE',
     headers: { 'Authorization': 'Bearer <viewer_token>' },
     body: JSON.stringify({ user_id: 'usr_123' })
   })
   

4. Capture 403 response

Evidence: Screenshot of DevTools showing 403 API response

Testing Time-Based Access

Scenario: Access expires after certain date

Test approach:

// User has temporary admin access until 2025-03-01
{
  "user": "temp_admin@company.com",
  "role": "Admin",
  "access_expires": "2025-03-01T00:00:00Z",
  "test_date": "2025-03-02T10:00:00Z",
  "expected": "access_denied",
  "test_result": "PASS"
}

Evidence: Screenshot showing access denied after expiration date

---

Common Mistakes and How Automation Prevents Them

Mistake 1: Testing Only in Staging Environment

Why it's a problem: Auditors want proof that production RBAC works

Manual risk: Teams test in staging, assume production is same

Automation solution: Automated tests run in production on schedule

Evidence requirement:

{
  "environment": "production",
  "environment_url": "https://app.yourcompany.com",
  "test_date": "2025-01-19T14:32:18Z",
  "evidence": "Production database and API tested"
}

Mistake 2: Forgetting to Test All Roles

Why it's a problem: Auditors want to see every role tested

Manual risk: Only test Viewer role, assume others work

Automation solution: Test script includes all roles automatically

Evidence checklist:

• ✅ Viewer role tested
• ✅ Editor role tested
• ✅ Admin role tested
• ✅ Custom roles tested (if any)

Mistake 3: Not Capturing Audit Logs

Why it's a problem: Auditors want proof that access denials are logged

Manual risk: Forget to screenshot logs or can't find relevant entries

Automation solution: Automatically queries logs and extracts relevant entries

Log query automation:

// Screenata queries CloudWatch for access denials
const logs = await cloudwatch.filterLogEvents({
  logGroupName: '/aws/application',
  startTime: testStartTime,
  endTime: testEndTime,
  filterPattern: '{ $.event = "access_denied" && $.user = "viewer@company.com" }'
})

Mistake 4: Inconsistent Test Documentation

Why it's a problem: Auditors flag inconsistencies between quarters

Manual risk: Different testers write different documentation styles

Automation solution: AI generates consistent descriptions every time

Example consistency:

Q1 2025: "User with Viewer role attempted to access /admin/users and received 403 error as expected."

Q2 2025: "User with Viewer role attempted to access /admin/users and received 403 error as expected."

Q3 2025: "User with Viewer role attempted to access /admin/users and received 403 error as expected."

---

Real-World Examples

Example 1: SaaS Application with 5 Roles

Company: Project management SaaS

Roles:

• Guest (view public projects)
• Member (view/edit assigned projects)
• Team Lead (manage team members)
• Admin (manage organization)
• Owner (billing and org deletion)

Test automation:

• 15 test cases (3 denied actions per role)
• Executed quarterly
• Evidence package: 45 screenshots + audit logs
• Time: 25 minutes per quarter (vs 5 hours manual)

Audit result: Zero findings on CC6.1

Example 2: FinTech with PII Access Controls

Company: Banking API platform

Special requirements:

• PII access requires specific role + MFA
• All PII access logged with justification
• Access reviewed quarterly

Test automation:

• Test PII access without MFA (should fail)
• Test PII access with wrong role (should fail)
• Test PII access with correct role + MFA (should succeed)
• Capture audit logs for all attempts

Evidence:

• Screenshots showing MFA prompts
• Access denial for non-compliant attempts
• Audit logs with justification field
• Quarterly access review reports

Audit result: Passed with auditor commendation for thoroughness

Example 3: Healthcare SaaS (HIPAA + SOC 2)

Company: Electronic health records platform

Special requirements:

• HIPAA requires RBAC for PHI
• SOC 2 CC6.1 requires proof of RBAC effectiveness
• Must test RBAC quarterly

Test automation:

• Test PHI access for each role
• Test emergency access override (break-glass)
• Capture audit logs for all PHI access
• Generate reports for both HIPAA and SOC 2

Evidence:

• Screenshots of RBAC denials for PHI
• Break-glass audit trail
• Role assignment documentation
• Quarterly review reports

Audit result: Passed both HIPAA and SOC 2 audits

---

Cost-Benefit Analysis: Manual vs Automated

Activity	Manual Time	Manual Cost	Automated Time	Automated Cost	Savings
Setup test users	30 min	$100	0 min (reuse)	$0	$100
Execute tests	60 min	$200	10 min	$33	$167
Capture logs	20 min	$67	0 min (auto)	$0	$67
Document results	45 min	$150	2 min (AI)	$7	$143
Format evidence	30 min	$100	1 min (auto)	$3	$97
Total per quarter	185 min	$617	13 min	$43	$574
Annual total	740 min	$2,467	52 min	$173	$2,294

Additional costs:

• Screenata tool: $1,788/year
• Net savings: $506/year + consistency improvements

Intangible benefits:

• ✅ Consistent evidence quality
• ✅ Reduced audit prep stress
• ✅ Continuous compliance posture
• ✅ Easier to scale with more roles

---

Implementation Checklist

Phase 1: Planning (Week 1)

• Document all user roles in your application
• List restricted features for each role
• Identify audit log location and format
• Create test user accounts for each role
• Define pass/fail criteria for each test

Phase 2: Tool Setup (Week 2)

• Install Screenata browser extension
• Configure RBAC test templates
• Connect to audit log system
• Set up Vanta/Drata integration
• Test first control end-to-end

Phase 3: First Quarterly Test (Week 3)

• Execute automated RBAC tests for all roles
• Review AI-generated evidence
• Verify screenshots are clear and complete
• Check audit logs captured correctly
• Export to Vanta/Drata

Phase 4: Ongoing Operations

• Set calendar reminders for quarterly tests
• Review and update test cases when roles change
• Archive evidence locally for backup
• Monitor for test failures and alerts

---

Key Takeaways

✅ CC6.1 requires quarterly proof that RBAC prevents unauthorized access

✅ Required evidence: Permission matrix, access denial screenshots, audit logs, test reports

✅ Manual testing takes 3 hours per quarter (12 hours/year)

✅ Automated testing takes 13 minutes per quarter (52 minutes/year)

✅ Automation ensures consistency across quarters and testers

✅ Auditors accept automated evidence when properly formatted with timestamps

✅ Integration with Okta/Azure AD captures role assignment data automatically

✅ API-level testing proves permissions enforced beyond UI

---

Get Started with Automated RBAC Evidence Collection

Screenata automates CC6.1 evidence collection with browser-based testing, AI-powered documentation, and integration with Vanta/Drata.

What you get:

• Browser extension for Chrome/Edge
• Pre-built RBAC test templates
• Automatic screenshot capture
• Audit log integration
• Quarterly scheduling and reminders
• Export to Vanta/Drata/PDF

Pricing: $149/month Setup time: 30-60 minutes Time savings: 2.5 hours per quarter

Start your 14-day free trial →

---

Related Articles

• How Do Compliance Teams Document Application-Level Tests Like Role-Based Access Automatically?
• Can I Integrate Automated Screenshot Documentation with Drata or Vanta?
• How to Automate SOC 2 Evidence Collection with Screenshots