Data Sources

Data-source security and permissions

Review provider access, credential handling, account boundaries, and what connector scopes do and do not imply.

Data-source security and permissions

Every connector operates inside a provider-defined authorization model: OAuth scopes, app-installation permissions, cloud roles, service principals, or API keys. The connection flow is the authoritative place to review the exact permissions requested for that provider and configuration mode.

Before connecting

  1. Use a dedicated app, role, or service identity where the provider supports one.
  2. Restrict the account, organization, project, site, or tenant boundary to the intended compliance scope.
  3. Prefer read-only permissions and remove optional capabilities you do not intend to use.
  4. Record who approved the connection, which environment it covers, and when it should be reviewed.
  5. Check provider plan/API limitations that can make a nominally successful connection incomplete.

Some provider APIs bundle read access broadly. The scope a provider requires can be wider than the subset Noru's collector currently stores. Authorization means the credential could call the allowed API; it does not mean every accessible field becomes a Noru record. Review the provider-specific setup text and your own provider audit logs.

Credential lifecycle

Noru stores connector credentials for scheduled collection. Rotate or revoke them through the provider and reauthenticate the integration when necessary. Offboard the connection when its owner, system, or scope is retired. A disconnected source stops future collection, but existing evidence may remain for audit/history until your retention/deletion workflow removes it.

After connecting

  • compare collected objects with the intended account boundary
  • inspect unexpected evidence, assets, identities, vendors, or findings
  • verify that sensitive values are not present in uploaded/manual evidence
  • review the provider's audit log for connector activity
  • set an owner for reauthorization and failure response
  • periodically re-review scopes after provider or Noru connector changes

A successful OAuth screen does not prove least privilege, complete collection, or continuous health. Authorization scope, collector implementation, provider response, and sync status are separate questions.

What Noru does with collected data

Collected evidence, assets, identities and findings are used to run your compliance program and nothing else. Two commitments bound the AI features that read them, and both are contractual — Section 4.6 of the Terms and Sections 3.5–3.6 of the DPA:

  • Nothing collected from your connected sources is used to train, fine-tune, or evaluate any AI or machine learning model, Noru's or a provider's.
  • Every AI call runs under zero data retention terms, so the model provider returns the output and retains no copy of the prompt or the response, with no human review queue.

This is usually the answer your own vendor questionnaire wants when it asks what a subprocessor does with data pulled from your cloud and identity providers. See Security for the full statement.