RSG does not simply connect tools and hope they work. Permissions, approvals, backups, logs, testing, and recovery procedures are designed into every system from the beginning — because these systems run real business operations and hold sensitive data.
A standard applied to every website, CRM, automation, portal, and custom system RSG delivers
RSG evaluates every project across the areas below. Which controls a system receives depends on what it does and the data it holds — security is selected to fit the project, not sold as a fixed bundle.
Security is part of the build
RSG systems are designed with controlled access, secure credentials, backups, audit trails, responsible-AI safeguards, and documented recovery from the beginning. Security is not added after the automation is already running.
AI should not have unlimited authority
RSG can require human approval before an AI system sends sensitive communications, changes records, approves financial actions, releases documents, or performs other high-risk tasks.
Know where your data goes
RSG documents the third-party platforms involved in each system, what they are used for, and what categories of information they may process.
Built for accountability
Important administrative, customer-data, and AI actions can be logged so a business understands what happened, who authorized it, and which records were affected.
The standard, area by area
Ten areas RSG evaluates on every project
Identity & access
The right people, the right access — and nothing more
Employees, administrators, customers, contractors, and vendors should only reach the information and functions their role requires. Access is designed before the system is built, not bolted on afterward.
Multifactor authentication
Secure account creation and login
Role-based access permissions
Least-privilege access
Session management
Account recovery controls
Administrative access restrictions
Optional single sign-on for eligible projects
Permissions are enforced on the server and, for databases, at the data layer — hiding a button is never treated as the control.
Data protection
Sensitive data is protected and never over-collected
RSG protects data in transit and, where the selected infrastructure supports it, at rest — and avoids collecting or keeping information a system does not actually need.
Encryption in transit
Encryption at rest when supported by the infrastructure
Secure database access
Sensitive-field protection
Data-retention controls
Data-deletion workflows
Export and portability controls
Restricted access to confidential information
Prevention of unnecessary data collection
Less data retained means less to lose. Retention rules are documented, not assumed.
Secrets management
Credentials stay out of the browser and out of source control
API keys and credentials belong in managed secret storage — never in frontend code, never committed to the repository, and never shared across environments.
No exposed API keys in frontend code
No credentials committed to source control
Environment-variable management
Managed secret storage where available
Restricted production credentials
Credential rotation procedures
Separate credentials for development, staging, and production
Immediate invalidation of compromised credentials
Infrastructure & environments
Development, staging, and production stay separate
Where appropriate, work happens in separate environments. Development data should not automatically contain real customer information, and production must not rely on test credentials, placeholder integrations, mock authentication, or developer bypasses.
Separate development, staging, and production environments
Real customer data kept out of development by default
No test credentials or mock authentication in production
Production debugging disabled
Demo systems isolated from production data
Secure deployment process
Backups & recovery
Recovery is planned, documented, and tested
It is not enough to say backups exist. RSG documents what is backed up, how often, how long it is retained, and how a restoration would actually be performed.
Automated database backups
Configurable backup frequency
Retention schedules
Restoration procedures
Recovery testing
File and document backup considerations
Business-continuity planning
Defined recovery expectations when in scope
Logging & accountability
A clear record of who did what, when, and to which record
Important administrative, customer-data, and AI actions are logged so a business can understand what happened and who authorized it — without ever writing passwords, keys, or full payment details into the logs.
Activity logs
Administrative audit logs
Authentication events
Permission changes
Record creation, modification, and deletion events
AI-generated action records
Integration-failure records
Exportable logs when appropriate
Responsible AI controls
AI should not have unlimited authority
For systems that generate content, make recommendations, access business data, or communicate with customers, RSG can require a human to approve high-risk actions before anything happens — and keeps untrusted input separate from instructions.
Human approval for high-risk actions
Permission-aware document access
Restricted tool access
Approved data-source boundaries
Prompt-injection and disclosure testing
Output validation and structured outputs
Rate limits and action limits
Escalation to a human
Audit trails for AI actions
Emergency disable controls
High-risk actions — sending contracts, issuing refunds, changing pricing, deleting records, sharing confidential documents — do not execute automatically without deliberate authorization.
Vendor management
Know where your data goes
RSG documents the third-party platforms involved in each system — hosting, databases, email, SMS, payments, analytics, AI models, storage, and authentication — what they are used for, and what categories of information they may process.
Vendor name and service
Business purpose and data handled
Hosting region when known
Security documentation and agreement status
Subprocessors
Access level
Renewal and review dates
Replacement or removal procedure
RSG does not automatically claim that any vendor is approved for a regulated industry.
Incident response
A plan for when something goes wrong
Every qualified project includes an incident-response procedure sized to its risk — how an incident is detected, who is responsible, how access is contained, how credentials are rotated, how systems are isolated, how services are restored, and how affected clients are notified.
Detection and ownership
Access containment
Credential rotation
System isolation
Log preservation
Service restoration
Client notification
Documented lessons and corrective actions
Testing & maintenance
Security is verified, then maintained
AI-enabled projects are tested against an internal checklist — prompt injection, sensitive-information disclosure, permission bypass, data leakage, excessive agency, and more — with results, severity, evidence, and retest status recorded.
Prompt-injection and indirect-injection testing
Sensitive-information disclosure testing
Permission-bypass and unauthorized-retrieval testing
Data-leakage testing between customers
Excessive-agency and unsafe-tool-call testing
Abuse and rate-limit testing
Backup restoration testing
Periodic security review
Human-in-the-loop
High-risk AI actions wait for a human decision
When an AI feature drafts a high-risk action, it does not execute automatically. It enters an approval queue where a person can approve, reject, edit, or escalate — and every AI action can be logged.
01Drafted by AI
02Awaiting approval
03Approved
04Executed
or Rejected / Escalated
Actions that require deliberate authorization
Sending contracts
Issuing refunds
Changing pricing
Deleting records
Approving estimates
Modifying permissions
Sharing confidential documents
Making financial commitments
Publishing public content
Sending sensitive customer communications
Scheduling expensive work
Executing database or infrastructure changes
Framework-informed development
Informed by NIST and OWASP guidance
The RSG Secure Systems Standard is informed by established security and responsible-AI principles. RSG organizes its internal AI risk process around four stages.
Govern
Decide who owns the AI, what it may do, and how much risk is acceptable.
Ownership and responsibilities
Acceptable use and risk tolerance
Approval requirements
Documentation standards
Vendor oversight
Incident escalation
Map
Understand the intended use, who it affects, and what could go wrong.
Intended use and users
Data sources and dependencies
Affected people and business consequences
Potential misuse
Regulatory considerations
Actions the AI can perform
Measure
Evaluate how well it works and how it fails.
Accuracy and reliability
Security and privacy
Prompt-injection resistance
Data-leakage risk
Failure behavior
Human-approval effectiveness and logging completeness
Manage
Put controls in place and keep them current.
Risk controls and restricted permissions
Human review and monitoring
Incident procedures and remediation
Model or vendor changes
Feature shutdown procedures
Periodic reassessment
OWASP-informed AI risks, in plain terms
Prompt injection
Untrusted input is kept separate from instructions and tested against injection.
Sensitive-information disclosure
The assistant is scoped so it cannot reveal data beyond a user's permissions.
Improper output handling
AI output is treated as untrusted — escaped when displayed, validated before any action.
Excessive agency
Tool access is restricted and high-risk actions require human approval.
Insecure integrations
Third-party connections are documented, scoped, and reviewed.
Unauthorized access
Authorization is enforced server-side and, for databases, at the data layer.
Unsafe dependency or vendor usage
Vendors and dependencies are documented and reviewed.
Unbounded resource consumption
Rate limits and action limits contain cost and abuse.
An honest word on compliance
Built using principles informed by NIST and OWASP guidance.
Security controls are selected based on project requirements.
Designed around secure development and responsible-AI practices.
Compliance-ready architecture may be available when specifically scoped.
Final compliance obligations depend on the client, industry, vendors, configuration, and legal requirements.
Security packaging
Security scaled to the system
Controls are grouped so the right depth of security fits each kind of project — from a standard website to a confidential private-AI deployment.
RSG Core Security
Standard websites and basic business systems.
Secure authentication
MFA for administrators
Environment-variable secret management
Encrypted connections
Automated backups
Basic activity logs
Secure deployment checklist
RSG Advanced Security
CRMs, customer portals, operations systems, and sensitive business workflows.
Granular role-based access
Detailed audit logging
Vendor and subprocessor records
Data-retention controls
Documented recovery procedures
Environment separation
Security testing
Incident-response documentation
RSG Responsible AI Controls
AI assistants, agents, communication tools, and automated decision workflows.
Human approvals for high-risk actions
Tool restrictions
Permission-aware retrieval
Prompt-injection testing
Output validation
Sensitive-data controls
AI action logs
Escalation procedures
Emergency disable controls
RSG Private AI Security
Organizations with greater confidentiality requirements.
Private-cloud or local deployment options
Restricted model and vendor access
Controlled knowledge ingestion
Network restrictions
Custom retention policies
Advanced access controls
Detailed audit logs
Confidentiality-focused architecture
Client-controlled approval procedures
Pricing is scoped per project. RSG does not publish fixed security pricing, and final compliance obligations depend on the client, industry, vendors, configuration, and legal requirements.
Questions
Frequently asked
Is RSG certified or compliant with SOC 2, HIPAA, or other frameworks?
No. RSG builds using principles informed by NIST and OWASP guidance, but it does not represent itself as certified, audited, or compliant with any framework unless that status has been independently verified for a specific engagement. Compliance-ready architecture can be scoped when a project requires it, and final compliance obligations depend on the client, industry, vendors, configuration, and legal requirements.
Does every system get every control?
No. Security controls are selected based on the project. A marketing website needs secure forms, spam protection, admin authentication, backups, and secure deployment. A CRM adds role-based permissions, audit logs, retention rules, and recovery procedures. An AI operations system adds tool restrictions, human approval, prompt-injection testing, and complete AI action logging.
How does RSG keep AI from doing something it shouldn't?
High-risk AI actions — sending contracts, issuing refunds, changing pricing, deleting records, sharing confidential documents, making financial commitments — do not execute automatically. They enter an approval queue where a human can approve, reject, edit, or escalate before anything happens, and every AI action can be logged.
What happens to my data, and where does it go?
RSG documents the third-party platforms involved in your system, what each is used for, and what categories of information it may process. Data is protected in transit and, where the infrastructure supports it, at rest. RSG also avoids collecting or retaining information a system does not actually need.
Are backups real, or just a checkbox?
RSG documents what is backed up, how often, how long it is retained, and how a restoration would be performed — and restoration is tested rather than assumed. Backup status shown in the admin console reflects real infrastructure or is clearly marked when it cannot be verified from the console.
What if there's a security incident?
Every qualified project includes an incident-response procedure sized to its risk: how an incident is detected, who is responsible, how access is contained, how credentials are rotated, how systems are isolated, how logs are preserved, how services are restored, and how affected clients are notified — with lessons and corrective actions documented.
Next step
Build a system that's secure from the start
Every engagement starts with a strategy call. We review the business and its data first, then design the controls that fit.