HI satakshi,

You need to enforce this in your code by checking whether the user has permission to perform the operation by making the appropriate CRUD/FLS calls:

isAccessible(), isDeletable(), etc.

See https://developer.salesforce.com/page/Enforcing_CRUD_and_FLSfor code samples

Note that isAccessible() checks also need to be performed on the fields used in SELECT or dynamic SOQL queries, even if the results are not returned to the user, whenever a standard field or sensitive custom field is being queried.

If the user does not have permission, then do not proceed with the operation, and instead notify the user about the missing permissions. They can then talk to the admin.
These types of checks can form a large part of your business logic, and implementing them should be one of the upfront design decisions of your app.

CRUD/FLS checks are performed automatically for you only at the Visualforce layer with standard components that accept sObjects as parameters (e.g. inputField, outputField). If this is all you're using, you can skip the checks. Also, standard controllers automatically do these checks, but if you write custom controllers or custom controller extensions or if you migrate your display code to the client (e.g. remoting or Lightning) then you need to do the checks yourself in the apex.

There is an official opensource apex library that makes this easier for you by combining the permissions check with the operation, exposing commands such as updateAsUser().

https://github.com/forcedotcom/force-dot-com-esapi

Larger scale projects may want to write their own data access library that enforces these checks in the way transparent to calling business logic and can use the ESAPI library as a helper. In that case be sure that the caller handles access control exceptions.

In addition to checking for CRUD/FLS, your code needs to either enforce record level access via the 'with sharing' keyword (mandatory for classes that read or write standard fields on enterprise objects), OR enforce your own custom permissions, which is only an acceptable option for when your classes only read or modify custom fields that are in your namespace. This also should be included in your data access code, with separate control paths for standard and custom fields if you decide to roll your own permissions model for custom fields.

Again, this needs to be designed up front, as it may be difficult to refactor large apps to respect the organization's security policies.

Please mark my solution as the best answer if it helps you.

Best Regards,
Nagendra.P