OSCOM Security and Permissions: How to Configure Access Controls for Your Team

Most teams do not think about permissions until something goes wrong. A contractor accidentally deletes a month's worth of scheduled content. An intern exports the entire customer database. A former employee's account still has admin access three months after they left. These incidents are not caused by malicious intent. They are caused by permission configurations that were either never set up properly or set up once and never maintained. As your team grows and your marketing operations become more complex, the gap between what people should be able to do and what they can actually do widens until an incident forces you to address it reactively instead of proactively.

OSCOM's security and permissions system is designed to make proper access control the default rather than an afterthought. It works on the principle of least privilege: every team member gets exactly the access they need to do their job and nothing more. This guide covers the complete permissions architecture, from individual user roles through team-based access patterns, API key management, audit logging, and compliance features. Whether you are a two-person startup or a fifty-person marketing department, this guide helps you configure access controls that protect your data without creating friction for your team.

Understanding the Permission Model

OSCOM's permission model is built on three concepts: roles, permissions, and scopes. Roles are named bundles of permissions that you assign to users (like "Editor" or "Admin"). Permissions are individual capabilities (like "publish content" or "view analytics"). Scopes define where a permission applies (like "all content" or "only content they created"). Together, these three concepts let you express precise access rules like "this person can edit content they created but cannot publish it or view analytics data."

The four default roles. OSCOM ships with four default roles that cover the most common access patterns. Owner has unrestricted access to everything: all content, all analytics, all settings, all team management, billing, and API configuration. This role should be limited to one or two people who are ultimately responsible for the OSCOM account. Admin has access to all operational features (content, analytics, outreach, SEO, market intelligence) and can manage team members and workspace settings. Admins cannot modify billing, delete the workspace, or manage API keys. This role is for senior team members who manage day-to-day operations. Editor can create, edit, and publish content, access analytics in read-only mode, and use operational tools (content engine, SEO recommendations, outreach sequences). Editors cannot modify settings, manage team members, or export data. This role is for content creators and marketing operators. Viewer has read-only access to content and analytics. Viewers cannot create, edit, delete, or export anything. This role is for stakeholders who need visibility (executives, board members, cross-functional partners) without operational access.

Permission granularity. Each default role is composed of specific permissions, and you can see exactly what each role can and cannot do in the Permissions Matrix (Settings then Security then Roles). The matrix lists every permission in OSCOM organized by module and shows which roles have each permission. The modules include Content (view, create, edit own, edit any, delete own, delete any, publish, unpublish, schedule), Analytics (view dashboards, create custom reports, export data, modify dashboard configuration), Outreach (view campaigns, create campaigns, send messages, access contact database, export contacts), SEO (view reports, run audits, modify settings, access competitor data), Market Intelligence (view reports, configure monitors, export intelligence data), and Settings (view settings, modify workspace settings, manage team, manage integrations, manage API keys, manage billing).

Custom roles. If the default roles do not match your team structure, create custom roles with exactly the permissions you need. Navigate to Settings then Security then Roles then Create Custom Role. Name the role, add a description, and then toggle individual permissions on or off. Custom roles are common for specialized team functions. A "Social Media Manager" role might have content creation and publishing permissions for social content only, analytics view access for social metrics, and no access to SEO, outreach, or settings. A "Data Analyst" role might have full analytics access including exports but no content creation or outreach permissions. A "Freelance Writer" role might have the ability to create and edit their own content drafts but not publish, delete, or view other team members' content.

Setting Up Permissions for Common Team Structures

The best permission setup is one that matches your team's actual workflow. Permissions that are too restrictive create friction (people constantly asking admins to do things for them) and permissions that are too loose create risk (people accidentally or intentionally accessing data they should not). Here are recommended permission configurations for common team structures.

Small team (2-5 people). Small teams usually have one person who manages everything (Owner) and two to four people who create and publish content (Editors). The permission setup is simple: Owner for the founder or marketing lead, Editor for everyone else. At this stage, granular permissions add complexity without much benefit because everyone on the team has context on everything. As the team grows beyond five people, revisit and tighten permissions.

Mid-size marketing team (5-15 people). Mid-size teams typically have specialized roles: content writers, SEO specialists, paid media managers, analytics professionals, and a marketing director. The recommended setup uses the Admin role for the marketing director and team leads, the Editor role for content writers and SEO specialists, a custom "Analyst" role for the analytics team (full analytics access, read-only content access, no outreach or settings), and a custom "Campaign Manager" role for paid media managers (outreach access, campaign analytics, no content creation or SEO modification). This structure keeps each specialist focused on their domain while preventing accidental modifications to areas outside their expertise.

Large team with external contributors (15+ people). Large teams often include external contributors: freelance writers, agency partners, consultants, and temporary contractors. These external contributors need enough access to do their work but should not see internal analytics, team communications, or strategic data. Create a custom "External Contributor" role with permissions limited to: create draft content (cannot publish), view only their own content (cannot see other contributors' work), no analytics access, no outreach access, no settings access, and no export capabilities. This role lets freelancers contribute content through OSCOM without exposing your internal operations.

Agency managing client workspaces. If you use OSCOM Multi-Workspace to manage client accounts, the permission model extends across workspaces. Agency team members get Organization-level roles (Organization Member for most, Organization Admin for account directors) and workspace-level roles for each client they work on. A writer working on three client accounts gets Editor access on those three workspaces and no access to other client workspaces. The agency owner gets Organization Owner for full visibility. Client stakeholders get Viewer access on their own workspace only, so they can monitor progress without operational access.

API Key Security and Management

API keys are the most overlooked security risk in marketing platforms. They are created once, pasted into an integration, and forgotten. But an API key with full access that is compromised gives an attacker the same capabilities as an admin user, without the protections of two-factor authentication, session limits, or login notifications. OSCOM's API key system is designed to minimize this risk through scoped permissions, key rotation, and usage monitoring.

Scoped API keys. When you create an API key in OSCOM (Settings then API then Create Key), you define its scope: which modules it can access and which actions it can perform. A key created for a CMS integration might only have permissions to create and update content. A key created for a reporting dashboard might only have read access to analytics data. A key created for an outreach integration might have permission to read contacts and create campaigns but not delete contacts or modify settings. Each key's scope should match exactly what the integration needs and nothing more.

Key naming and documentation. Every API key should have a descriptive name that identifies what it is used for: "Zapier Content Sync," "Custom Dashboard Read-Only," "Outreach CRM Integration." OSCOM also lets you add a description with more detail: which system uses the key, who created it, when it was last reviewed, and a link to the integration documentation. This metadata is critical when reviewing keys months or years after creation. Without it, you end up with a list of anonymous keys and no way to know which are still in use and which can be safely revoked.

Key rotation. API keys should be rotated periodically, even if there is no evidence of compromise. OSCOM supports two rotation strategies. Manual rotation lets you generate a new key with the same scope as an existing key, update the integration to use the new key, and then revoke the old key. Automatic rotation lets you set a rotation interval (30, 60, or 90 days) for a key. When the rotation interval expires, OSCOM generates a new key and enters a grace period where both the old and new keys work. This gives you time to update the integration without downtime. After the grace period (configurable, default 7 days), the old key is automatically revoked.

Key usage monitoring. OSCOM tracks every API call made with each key: the endpoint called, the timestamp, the response status, and the source IP address. This usage data serves two purposes. First, it helps you identify unused keys. If a key has not been used in 90 days, it is likely associated with an integration that was disconnected or replaced, and the key can be safely revoked. Second, it helps you detect suspicious activity. If a key that normally makes 50 calls per day suddenly makes 5,000 calls, or if calls start coming from an unexpected IP address, that may indicate the key has been compromised.

Two-Factor Authentication and Login Security

Passwords alone are not sufficient protection for marketing platforms that contain customer data, analytics, content strategies, and integration credentials. OSCOM supports multiple two-factor authentication (2FA) methods and provides account-level controls for enforcing 2FA across your team.

2FA methods. OSCOM supports three 2FA methods. Authenticator app (TOTP) works with any standard authenticator app (Google Authenticator, Authy, 1Password) and generates time-based one-time codes that change every 30 seconds. This is the recommended method for most users because it is widely supported, does not depend on phone service, and cannot be intercepted through SIM swapping. SMS codes send a one-time code to your phone via text message. This method is convenient but less secure than authenticator apps because SMS messages can be intercepted through SIM swapping attacks. Security keys (WebAuthn/FIDO2) support hardware security keys like YubiKey or built-in platform authenticators like Touch ID and Windows Hello. This is the most secure method because the authentication factor is a physical device that cannot be remotely compromised.

Enforcing 2FA for your team. Organization Owners and Admins can require 2FA for all team members through Settings then Security then Authentication Requirements. When 2FA is required, team members who have not set up 2FA are prompted to configure it at their next login. They cannot access any OSCOM features until 2FA is configured. You can also set the minimum 2FA method: if you require authenticator app or security key, team members cannot use the less secure SMS method.

Session management. OSCOM's session management features control how long login sessions last and what triggers a re-authentication requirement. Configurable options include session timeout (how long before an inactive session expires, default 24 hours), maximum session duration (the absolute maximum time a session can remain active regardless of activity, default 30 days), concurrent session limit (how many active sessions a user can have simultaneously, default 5), and re-authentication for sensitive actions (requiring password and 2FA confirmation before critical actions like changing permissions, revoking API keys, or exporting data).

IP allowlisting. For organizations with fixed office locations or VPN infrastructure, IP allowlisting adds an additional security layer by restricting account access to specific IP addresses or CIDR ranges. When IP allowlisting is enabled, login attempts from non-allowlisted IPs are rejected even if the credentials and 2FA code are correct. This prevents account access even if credentials are fully compromised, as long as the attacker is not on your network. Configure IP allowlisting in Settings then Security then Network. Add your office IP addresses, VPN exit points, and any other locations where team members need to access OSCOM. Include a backup IP (like a mobile hotspot or a secondary office location) in case your primary network goes down.

Audit Logging and Activity Monitoring

Audit logs are the security system's memory. They record what happened, who did it, when it happened, and from where. Without audit logs, investigating a security incident means guessing what happened. With comprehensive audit logs, you can reconstruct the exact sequence of events that led to an incident and determine its scope and impact.

What gets logged. OSCOM logs every significant action across all modules. Authentication events include successful and failed login attempts, 2FA challenges, password changes, and session creation and termination. Content events include creation, editing, publishing, unpublishing, deletion, and content imports. Permission events include role assignments, role modifications, team member invitations, and team member removals. Data events include analytics report generation, data exports, contact database queries, and API key creation and revocation. Settings events include workspace configuration changes, integration connections and disconnections, and billing modifications.

Log detail and retention. Each log entry includes the action performed, the user who performed it, the timestamp (UTC), the source IP address, the user agent (browser and device information), and the affected resource (the specific content item, user, setting, or data object that was changed). For content changes, the log also includes a diff showing what was modified. Logs are retained for 12 months on standard plans and 36 months on enterprise plans. Logs can be exported to CSV for integration with external SIEM (Security Information and Event Management) systems or for compliance documentation.

Real-time alerts. You can configure real-time alerts for specific audit log events. Common alert configurations include: alert on failed login attempts exceeding a threshold (potential credential stuffing attack), alert on permission changes (someone modifying roles or adding users), alert on data exports (someone downloading analytics data or contact lists), alert on API key creation or revocation, and alert on bulk content changes (someone deleting or modifying multiple content items). Alerts can be sent via email, Slack webhook, or OSCOM's in-app notification system. Configure alerts in Settings then Security then Alert Rules.

Using audit logs for investigations. When an incident occurs (unauthorized content changes, suspected data leak, unexplained permission changes), the audit log is your primary investigation tool. Navigate to Settings then Security then Audit Log and use the filters to narrow down the relevant events. Filter by user (who might have caused the issue), by action type (what type of action caused the issue), by date range (when the issue occurred), and by affected resource (which specific content, user, or setting was affected). Export the filtered logs as evidence for your investigation report.

Data Protection and Privacy Controls

Marketing platforms handle data that is subject to privacy regulations: email addresses, behavioral analytics, contact databases, and customer interaction histories. OSCOM includes data protection features that help you comply with GDPR, CCPA, and other privacy regulations without requiring a separate privacy management platform.

Data classification. OSCOM classifies data into three categories: public (published content, public analytics summaries), internal (draft content, team communications, workspace settings), and sensitive (contact databases, email content, analytics with personal identifiers, API keys). Permissions are calibrated to these classifications. Public data is viewable by all team members. Internal data is viewable by Editors and above. Sensitive data is viewable only by Admins and Owners, unless explicitly shared through a custom role permission.

Data export controls. Exporting data out of OSCOM is a high-risk action because exported data leaves the platform's access controls. OSCOM restricts export capabilities to specific roles (Admin and Owner by default) and logs every export event with full detail: who exported, what was exported, when, and the file format. For organizations that need stricter export controls, you can disable exports entirely for all roles except Owner, require re-authentication before any export, or limit export scope (for example, allow analytics export but not contact database export).

Contact data handling. If you use OSCOM's outreach module, the contact database contains personal data that is subject to privacy regulations. OSCOM provides tools for managing this data responsibly. Data retention policies let you automatically delete contact records that have not been active for a specified period (configurable from 6 to 36 months). Consent tracking records when and how each contact's data was collected and whether they have consented to marketing communications. Data subject requests can be processed through the Privacy section in Settings, where you can search for a specific contact and execute their data access request (provide a copy of their data) or data deletion request (permanently remove their data from all OSCOM systems including backups, within 30 days per GDPR requirements).

Encryption. OSCOM encrypts data at rest (stored data) using AES-256 encryption and data in transit (data moving between your browser and OSCOM's servers) using TLS 1.3. API communications are encrypted end-to-end. Backup data is encrypted with a separate key. These encryption standards meet the requirements of SOC 2 Type II, ISO 27001, and GDPR's security provisions.

Integration Security

OSCOM integrates with numerous third-party services: Google Search Console, GA4, CRM systems, email platforms, social media accounts, and advertising platforms. Each integration creates a potential security surface that needs to be managed. OSCOM's integration security features help you maintain control over these connections.

OAuth-based integrations. Most OSCOM integrations use OAuth, which means you authenticate directly with the service provider (Google, HubSpot, LinkedIn) and OSCOM receives a scoped access token rather than your credentials. This is more secure than sharing passwords because the token can be scoped to specific permissions (read-only analytics data, for example), the token can be revoked without changing your password, and OSCOM never sees or stores your password for the integrated service. Review connected integrations periodically in Settings then Integrations. Each integration shows its scope (what data it can access), connection date, last used date, and connected by (which team member authorized it). Revoke integrations that are no longer needed.

Webhook security. If you use webhooks to send OSCOM data to external systems, configure webhook signing to verify that incoming webhook payloads were actually sent by OSCOM and not spoofed by an attacker. OSCOM signs each webhook payload with an HMAC-SHA256 signature using a secret key that you configure. The receiving system verifies the signature before processing the payload. Without webhook signing, anyone who discovers your webhook URL can send fabricated data to your system.

Integration access control. Only Admins and Owners can connect or disconnect integrations by default. This prevents team members from connecting unauthorized services or disconnecting critical integrations. If you need to delegate integration management to specific team members without giving them full Admin access, create a custom role with the "manage integrations" permission and assign it to those team members.

Security Maintenance: Ongoing Best Practices

Security configuration is not a one-time task. Teams change, integrations change, and threats evolve. These ongoing practices keep your OSCOM security posture strong over time.

Quarterly access review. Every quarter, review your team's access by running through three questions for each team member. Does this person still need access to OSCOM? (If they left the company or changed roles, remove or update their access.) Is their role still appropriate? (If they were promoted or their responsibilities changed, their role may need adjustment.) Are they using the access they have? (If someone has Editor access but has not logged in for 90 days, consider whether they still need the access or if Viewer would be sufficient.) OSCOM's Team Activity report (Settings then Team then Activity) shows each team member's last login date and activity level, making it easy to identify inactive accounts.

Prompt offboarding. When a team member leaves, remove their access within 24 hours. OSCOM's offboarding workflow (Settings then Team then select user then Offboard) revokes the user's login access, terminates all active sessions, reassigns any content or campaigns owned by the user to a specified team member, revokes any API keys the user created, and generates an offboarding report listing all actions the user took in their last 30 days. Delayed offboarding is one of the most common security gaps in marketing teams because the urgency of removing access is not felt until after an incident occurs.

API key hygiene. Review your API keys quarterly alongside your team access review. For each key, verify that the integration is still active and the key is still needed, confirm that the key's scope is still appropriate (if the integration's needs have changed, update the scope), check the key's usage logs for unusual activity, and rotate keys that have not been rotated in 90 or more days. Revoke any keys that are no longer in use. Unused keys are a pure liability because they provide access without serving any function.

Security alerts review. Review your security alert configuration semi-annually. As your OSCOM usage evolves, the alert rules that made sense six months ago may need adjustment. New modules or features may require new alert rules. Alert thresholds may need tuning (too many false positives means alerts get ignored; too few alerts means real issues are missed). New team members may need to be added to alert distribution lists. The goal is to keep your alert system sensitive enough to catch real issues but specific enough that every alert warrants attention.

Compliance and Regulatory Considerations

If your organization operates in a regulated industry or handles data subject to specific privacy laws, OSCOM's security features support several compliance frameworks. Understanding which features map to which requirements helps you configure OSCOM to meet your specific compliance needs.

SOC 2 Type II. SOC 2 requires demonstrable controls over data security, availability, processing integrity, confidentiality, and privacy. OSCOM features that support SOC 2 compliance include role-based access control (security), audit logging (security, processing integrity), encryption at rest and in transit (confidentiality), session management and 2FA (security), data retention policies (privacy), and regular infrastructure monitoring (availability). OSCOM's own infrastructure is SOC 2 Type II certified, meaning the platform itself has been audited for these controls.

GDPR. GDPR requires specific data handling practices for personal data of EU residents. OSCOM features supporting GDPR compliance include data subject request handling (right of access, right to deletion), consent tracking in the contact database, data retention policies with automatic deletion, data portability (export personal data in machine-readable format), privacy impact assessment support (documentation of data processing activities), and data processing agreement (DPA) available for OSCOM customers as data processors.

CCPA. CCPA requires businesses to disclose data collection practices and honor consumer requests regarding their personal data. OSCOM supports CCPA through the same data subject request handling used for GDPR, data inventory features that document what personal data is collected and stored, and opt-out mechanisms for sale of personal information (OSCOM does not sell personal data, but the tools exist for tracking opt-out requests if your business processes require them).

HIPAA. If your marketing operations handle protected health information (common for healthcare and health tech companies), OSCOM's enterprise plan includes HIPAA-compatible features: a signed Business Associate Agreement (BAA), additional access controls and audit logging for PHI, encryption standards meeting HIPAA technical safeguards, and restricted data export capabilities for PHI-containing records. Note that HIPAA compliance requires configuration on your end as well. OSCOM provides the tools, but you are responsible for configuring them according to your organization's HIPAA compliance program.

Security is not a feature you enable once and forget. It is an ongoing practice that evolves with your team, your data, and the threat landscape. The teams that have the fewest security incidents are not the ones with the most sophisticated tools. They are the ones that follow basic practices consistently: least-privilege permissions, mandatory 2FA, regular access reviews, prompt offboarding, and API key hygiene. OSCOM provides the infrastructure to implement these practices. The practice itself is your responsibility. Start with the basics, build consistency, and layer on advanced features as your team and compliance requirements grow. A security posture built on consistent fundamentals is more resilient than one built on occasional bursts of attention followed by months of neglect.