GovFrame is a multi-company data governance service. Functional security starts with a simple rule: a company’s data, configurations, relationships, audit records, and operations remain separate from those of other companies. The application determines the company context before authorizing a query or action; changing an identifier in the browser does not grant access to another company.
Protection combines identity, membership, role, capability, scope, and module. The service enforces it even when an option is not visible. For example, a Data Steward can maintain business objects only in the assigned Domains or Subdomains.
Before you begin
- Role: The Administrator reviews access for their company. Global operations are reserved for authorized Superadministrators or Platform Administrators; other profiles operate within their responsibilities and scope.
- Module: Access administration and the relevant business module must be enabled. A disabled module cannot be operated by knowing a route or modifying parameters.
- Preconditions: Confirm a valid session, active membership, a company in a state that allows normal operation and, where applicable, the Domain, Subdomain, or Repository involved in the action.
Recommended workflow
-
Confirm the effective company context. GovFrame normally resolves it from the normalized hostname. A Superadministrator may select an available company for normal operation as part of a platform task; ordinary users cannot freely choose another company. The same identity may have different memberships in different companies.
-
Review the complete authorization before acting. GovFrame checks membership, role, capability, object scope, and module. The Administrator has company-wide scope; the Data Engineer has technical Repository scope; and Data Owners or Data Stewards have an assigned taxonomic scope. The global Superadministrator role does not remove these checks.
-
Maintain isolation in associations. Every object and relationship must belong to the effective company. An association between an Attribute, a technical field, a Rule, or a Contract documents traceability, not permissions. Check the taxonomic context and recorded relationships before attributing a dependency.
-
Use the intended identity flows. GovFrame supports local sign-in, access recovery, and federated authentication. Local passwords are stored as hashes, never in plain text. For a federated identity, verified email is checked strictly; an ambiguous signal must not be accepted as verification. Do not share passwords, tokens, recovery links, or authentication data in comments, evidence, or operational records.
-
Treat sensitive changes as session events. Sessions are carried by an HTTP-only cookie and checked against the current account state. When changing their own password, the user flow may renew only the current session. In contrast, a token-based reset, an administrative reset, suspension, rejection of registration, or a role or scope change revokes the affected sessions. After one of these changes, ask the person to authenticate again rather than trying to reuse a previous session.
-
Apply the same precautions to connectors and files. Credentials are not returned to the client; secrets and private files remain in secure storage, while the database retains references and metadata. Connectors validate destinations and verify TLS by default. This does not authorize client connections or guarantee scheduled scans: those depend on configuration and technical scope.
Synthetic example: A fictional person changes from Data Steward to User for a Domain. The role or scope change invalidates the affected previous sessions. After signing in again, the person can participate only in the records and tasks permitted by their new profile, scope, and enabled modules; keeping an old URL does not restore editing access.
Current state limitations and controls
- Security is not based on hiding options: the service rejects operations without permitted membership, capability, scope, or module.
- Disabling a module blocks its operation and may hide its access points, but does not automatically delete data already recorded. Reactivating a module remains subject to role, scope, and the state of the data.
- Risks, alerts, or controls may be displayed as information derived from quality rules, policies, workflows, tasks, contracts, classifications, or certifications. There is no independent Risks or Controls catalog that replaces these objects.
- This guide describes documented functional controls; it does not disclose secrets, personal identifiers, infrastructure details, credential lifetimes, or internal authentication procedures.
Expected result
After the review, each action is linked to an effective company and verifiable authorization. People access only the objects and modules appropriate to them, and sensitive changes require access to be renewed when applicable.
For more information about object context and responsibilities, see Object model and relationships, How to read the relationship map, Roles, capabilities, and scope and Modules and dependencies.